On Saturday, 18 January 2014 at 01:05:50 UTC, Walter Bright wrote:
Because I've tracked down the cause of many, many null pointers, and I've tracked down the cause of many, many other kinds of invalid values in a variable. Null pointers tend to get detected much sooner, hence closer to where they were set.
Some null pointers. The ones that were set in the current call-chain, but not the long-lived ones.
Anyway, pointers are special since they link together subsystems. Yes, it is better to have a null-value than a pointer to a random location, so "null" isn't the worst value for a pointer. It is the best arbitrary wrong value, but there is nothing wrong with saying "Hey, when we are wrong about User identity, we want to keep the system running assuming a Guest identity".
However C-like null values conflate a wide array of semantics, I think you can have near half a dozen types of null values in a database. In c-like languages null can mean: not-yet-initialized (used too early), failed-computation (bottom), entity-shall-not-have-subentity (deliberate lack of), empty-container (list is empty), service-not-ready (try again), etc.
So yeah, it would be nice if the language is able to distinguish between the different semantics of "null" of different pointer types and convert them into something sensible when "cast" to a different type.
For some pointer types it might make sense to kill the thread, for others it would make sense to throw an exception, for others it might make sense to allocate an empty object, for others it might make sense to use a dummy/sentinel.
It isn't universally true that the best option is to core dump, but you could do both. You could fork(), core-dump the fork, and recover the original.
