If you have a possible null, then check for it *yourself* sometimes you know its null, sometimes you don't have any control. However, the compiler has no way of knowing that. Its basically an all-or-nothing thing with the compiler.
However, the compiler can (and I think does) warn of possible null-related errors. It doesn't fail, because, again, it can't be certain of what is an error and what is not. And it can't know, since that is the Halting Problem. I'm not sure what the fuss is here, we cannot demand that every little convenience be packed into D, at some point we need to face facts that we are still programming, and sometimes things go wrong. The best arguments I've seen so far is to install a handler that catches the SEGFAULT in linux, and does whatever SEH stuff it does in windows and print a stacktrace. If this happens in a long-running process, then, to be blunt, tough. Unless you're telling me that the only way to reproduce the bug is to run the program for the same amount of time in near-identical conditions, then sir, you fail at being a detective. If you have a specific need for extreme safety and no sharp corners, use Java, or some other VM language, PHP comes to mind as well. If you want a systems programming language that is geared for performance, with modern convenience then stick around, do I have the language for you! Stop thinking in hypotheticals, because no language can cover every situation; "What if this is running in a space ship for 12 years and the segfault is caused by space bees?!" is not something we should be thinking about. If a process fails, then it fails, you try to figure out what happened (you do have logging on this mysterious program right?" then fix it. Its not easy, but if it was easy, we'd be out of jobs. </rant> -- James Miller
