null [re: spec#]

[foobar]

Nick Sabalausky Wrote:

> "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.
> 

You seem to contradict yourself a bit here. As you pointed out yourself bellow, if you really *want* to use nullable types than you should explicitly use option!T instead of T. This is how those data structures you mentioned are implemented in languages such as ML.  e.g.

datatype Tree = Leaf | Tree of ('a * Tree * Tree)

usage example: 
fun sum Leaf = 0 |
     sum Tree(val, left , right) = val + sum (left) + sum (right)

The important point here is that it won't COMPILE without the first part that handles the Leaf. This makes the use of null explicit and the compiler will verify that you are using nulls correctly.

In current D, there is no check to prevent compiling of:
int sum(Tree tree) { // doesn't handle case of null tree !!!
  return tree.value + sum(tree.left) + sum(tree.right);
}

This is not the OO null object idiom and there's no re-invention of null here since I haven't discussed the implementation of Option(T) at all. 
IMO it should be a language built-in just like const is in order to get the full benefits like in ML.

> 
> > 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.
> 
>