On Wednesday, 26 July 2017 at 03:16:44 UTC, Walter Bright wrote:
On 7/25/2017 6:09 PM, Steven Schveighoffer wrote:
Likewise, because D depends on hardware flagging of
dereferencing null as a segfault, any platforms that *don't*
have that for C also won't have it for D. And then @safe
doesn't even work in D code either.
I spent 10 years programming on DOS with zero memory
protection, and people have forgotten how awful that was. You
couldn't simply instrument the code with null pointer checks,
either, because then the program would be too big to fit.
The solution finally appeared with the 286 DOS Extenders, which
ran in protected mode. I switched to doing all my development
under them, and would port to DOS only after passing all the
test suite.
D is definitely predicated on having hardware memory protection.
The C/C++ Standards are still hanging on to EBCDIC, 10 bit
bytes, non-IEEE floating point, etc. It's time to let that crap
go :-)
One C++ programmer told me that C++ could handle any character
set. I asked him how RADIX50 was supported. Segfault! (I
learned to program on RADIX50 systems.)
D made some fundamental decisions:
* Unicode
* 2's complement
* 8 bit bytes
* IEEE arithmetic
* memory protection
* fixed sizes for integral types
* single pointer type
* >= 32 bit processors
that relegated a lot of junk to the dustbin of history. (It's
awful pretending to support that stuff. C and C++ pretend do,
but just about zero programs will actually work on such
systems, because there aren't any to try the code out on.)
And alone for that list of decision do I love you. I can not hear
anymore all the crap about "undefined behaviour", "nasal demons"
and optimizer that think that they are entitled to sabotage
programs because he is an over zealous language lawyer in the C
world practicing POOP (premature optimisation oriented
programming).
