Spec#, nullables and more

[Gary Whatmore]

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'm seeing it. The other arguments for non-null types also fall short because non-nulls don't solve basic problems like arrays, basic collections in the library (custom fill policy). Has any mainstream language adopted non-null types? No they haven't because the idea is broken.