Null references redux

[Walter Bright]

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.