Spec#, nullables and more

[Adam Burton]

Walter Bright wrote:

> Adam Burton wrote:
>> I wouldn't consider that as the same thing. null represents the lack of a
>> value where as 25 is the wrong value. Based on that argument the
>> application should fail immediately on accessing the item with 25 (not
>> many moons later) in the same manner it does nulls, but it doesn't
>> because 25 is the wrong value where as null is a lack of value.
>> 
>> As with the array allocation example earlier you initialise the array to
>> nulls to represent the lack of value till your application eventually
>> gets values to assign to the array (which may still be wrong values). As
>> shown by my alternative example non-nulls allow you to define that a
>> variable/parameter wants a value and does not work when it receives
>> nothing. However in the case of the array because all the information is
>> not there at the point of creation it is valid for the array items to
>> represent nothing till you have something to put in them.
> 
> 
> I am having a real hard time explaining this. It is conceptually *the same
> thing*, which is having an enforced subset of the values of a type.
I *think* I undertand what you mean, however I also think I failed to 
explain myself correctly. After reading bearophiles post I think he put it 
in much better terms of null being a common case that is handled in common 
way. The value 25 requires far more context for the compiler to identify it 
as a bad value and determine how the developer should handle it. null can 
still cause logic errors in the same way 25 can (which could lead to the 
application outputting bad data or crashing) but there is one particular 
case that always results in the application behaving in an unexpected manner 
(attempting to use a null reference on a class type) that makes it different 
and the compiler can help by enforcing checks. Without non-nullables 
enforcing that check would be tiresome as it is going to happen all over the 
place, with non-nullables you actually get the oppurtunity to reduce the 
amount of checks while also helping the developer check when they should be.

The non-nullable propsal doesn't eliminate NPE but it allows you to narrow 
the locations of the error. I know most of my code doesn't use nulls (you 
might say I avoid them like the plague) but sometimes code calls for the use 
of nulls, so if I can reduce the amount of code where a null can go then I 
have much less code to debug.