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.
- Re: Spec#, nullables and more Roman Ivanov
- Re: Spec#, nullables and more Walter Bright
- Re: Spec#, nullables and more Rainer Deyke
- Re: Spec#, nullables and more Walter Bright
- Re: Spec#, nullables and more Roman Ivanov
- Re: Spec#, nullables and more tls
- Re: Spec#, nullables and more bearophile
- Re: Spec#, nullables and more retard
- Re: Spec#, nullables and more Walter Bright
- Re: Spec#, nullables and more Adam Burton
- Re: Spec#, nullables and more Walter Bright
- Re: Spec#, nullables and more Gary Whatmore
- Re: Spec#, nullables and more bearophile
- Re: Spec#, nullables and more Gary Whatmore
- Re: Spec#, nullables and more Simen kjaeraas
- Re: Spec#, nullables and more bearophile
- Re: Spec#, nullables and more Denis Koroskin
- Re: Spec#, nullables and more Adam Burton
- Re: Spec#, nullables and more Walter Bright
- Re: Spec#, nullables and more bearophile
- Re: Spec#, nullables and more Walter Bright