Andrei Alexandrescu wrote:
But that's a false choice. You don't choose between a crashing program
and an out-of-control program. This is the fallacy. The problem is the
way Walter puts it it's darn appealing. Who would want a subtly
incorrect program?
Oh, I've heard people argue for them.
Null references are useful to implement optional arguments without any
overhead by an Optional!T wrapper. If you disallow null references
what would "Object foo;" initialize to then?
The default should be non-nullable references. You can define nullable
references if you so wish. The problem is, Walter doesn't realize that
the default initialization scheme and the optional lack thereof by using
"= void" goes straight against his reasoning about null objects.
If there was a reasonable way of having NaN values for ints, D would use
them. So we're stuck with a less than ideal solution, which is default
initializing them to 0. At least you get repeatable results from that,
rather than randomly wrong ones.
"=void" is justifiable in certain optimization cases. D is, after all, a
systems programming language with back doors there when you need them.
The problem with non-nullable references is what do they default to?
Some "nan" object? When you use a "nan" object, what should it do? Throw
an exception?
The problem with null references is not the canary dying, it's that
there's a logic error in the user's code. Putting a gas mask on the
canary keeps it from dying, but the gas is still seeping in, you just
don't know it.
