Null references (oh no, not again!)

[Walter Bright]

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.


> 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?