null [re: spec#]

[Nick Sabalausky]

"foobar" <foo at bar.com> wrote in message 
news:ib3a8k$1i58$1 at digitalmars.com...
> 1. the INVENTOR of the "reference" concept himself admits that this is a 
> flawed design.
> see: 
> http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake
>

First of all, "appeal to authority" is a logical fallacy. Second, there are 
plenty of cases where run-time nullability is useful and where lack of it is 
problematic at best: A tree or linked list, for example. The "null object" 
idiom doesn't count, because all it does is just reinvent null, and in a 
pointlessly roundabout way.


> 2. "null" is an a type-system attribute, hence should be checked at 
> compile time and would have ZERO affect on run-time performance.
> Same as assigning a string value to an int variable.

I strongly agree with this.

On a related note, I *hate* that D silently sticks in a default value 
whenever anything isn't properly inited. This is one thing where I really 
think C# got it right, and D got it wrong. And waving the "It's not leaving 
it with an undefined value like C does!" banner is an irritating strawman: 
Yea, it's better than C, but it still sucks.

I also dislike that D's reference types being nullable by default is 
inconsistent with its value types. (Yea, naturally reference and value types 
are going to have inherent differences, but nullability shouldn't be one of 
them.)


> 3. the notion of an "undefined" state for a type can be generally 
> implemented by the OPTION type and D pointers are an ad hoc implementation 
> of this concept.
> see: http://en.wikipedia.org/wiki/Option_type
> Any type can be wrapped by an OPTION type. trying to do the converse of 
> this is impractical and is bad design.
>

I strongly agree with this, too.

> 4. As already pointed by others, Walter's array should be:
> Option!T[] array;

Only if you actually *want* to allow null elements.

> 5. C programmers use null pointers and other special "canary" values as 
> Walter described mainly as rcodes. This is a BAD and bug-prone way of 
> handling errors and is replaced in D by a MUCH better mechanism called 
> "Exceptions".

Absolutely agree.