Regarding people that desire a compiler switch to add run-time tests inside the binary that guard against null seg-faults to turn turn them into errors with a stack trace: I have recently shown the D language to a friend. She answered me that most code she writes is for the Web and it's not CPU-bound.
So maybe for her D language is not needed, other more flexible languages are better for her. On the other hand if you already know D and you already use D for other CPU-intensive purposes you may want to use it for situations where a very high performance is not necessary at all. In such situations you don't compile in release-mode (leaving array bound tests on), and maybe you want null deference exceptions too, and other things (and tolerating some more bloat of the binary). Things like integral overflow errors and null errors allow you to use D in other niches of the programming landscape, while they do not hurt high performance D code at all because you are able to refuse those things with a compiler switch (the disadvantage is a little more complex compiler, but I think in this case this is acceptable). Generally not giving such choice to the programmers restricts the applicability and ecological niche of the D language, giving back no gain. Bye, bearophile
