Null references (oh no, not again!)

[Andrei Alexandrescu]

Walter Bright wrote:
> Daniel Keep wrote:
>> I need to know when that null gets stored, not when my code trips over
>> it and explodes later down the line.
> 
> Ok, I see the difference, but I've rarely had any trouble finding out 
> where the assignment happened. In fact, I can't remember ever having a 
> problem finding that.
> 
> That's because the null pointer exception is nearly always repeatable, 
> so it isn't hard to work backwards. The non-repeatable ones have been 
> due to memory corruption, which is a different issue entirely.

The world is more diverse than one environment. When I run 200 jobs on a 
cluster, failure from null pointer usage comes back with no file and 
line information, no debugger nicely starting, no nothing. And it's not 
easy to reproduce that on a small machine with GUI and all.

>> Non-nullable types (or proxy struct or whatever) means the code won't
>> even compile if there's an untested path.  And if we do try to assign a
>> null, we get an exception at THAT moment, so we can trace back to find
>> out where it came from.
> 
> Yes, I understand that detecting bugs at compile time is better. But 
> there's a downside to this. Every reference type will have two subtypes 
> - a nullable and a non-nullable. We already have const, immutable and 
> shared. Throwing another attribute into the mix is not insignificant. 
> Each one exponentially increases the combinations of types, their 
> conversions from one to the other, overloading rules, etc.
> 
> Andrei suggests making a library type work for this rather than a 
> language attribute, but it's still an extra thing that will have to be 
> specified everywhere where used.
> 
> There are a lot of optional attributes that can be applied to reference 
> types. At what point is the additional complexity not worth the gain?

The added language complexity is very small and not visible to the user. 
You change the default behavior. The library takes care of the rest. 
Non-null is not const, not invariant, not shared, and should not be 
compared in cost and benefits with them.

And there is no reference type with two subtypes. It's one type in the 
language and one in the library. Maybe-null (the library) is a supertype 
of non-null (the default).

Again: there is no "adding" to the language. It's changing. You don't 
need to even look at overloading, combinations etc. All you need to look 
at is constructors. (Oh, Bartosz and I found a couple of other bugs in 
constructors last night too.)


Andrei