Spec#, nullables and more

[Bruno Medeiros]

On 06/11/2010 19:57, 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.

Indeed, it is the same thing: to enforce a subset of the values of a 
type (and these are contracts, generally speaking).

So, Adam, if you specify as a contract that a certain variable/value 
should have never 25 on it, and one time it is accessed and it does have 
25 there, then there is a bug, and you should consider your application 
to have failed immediately (even if in practice it likely won't, well, 
not immediately at least).

The only difference in these cases is that wanting to assert something 
to be nonnull (and have the compiler check that) is *much* more common 
than any particular restriction on numeric values. But it is not a 
difference in nature, or concept.


-- 
Bruno Medeiros - Software Engineer