Null references (oh no, not again!)

[Denis Koroskin]

On Tue, 03 Mar 2009 21:59:16 +0300, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:

> Daniel Keep wrote:
>> Just noticed this hit Slashdot, and thought I might repost the abstract
>> here.
>>   
>> http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake
>>
>>> I call it my billion-dollar mistake. It was the invention of the null
>>> reference in 1965. [...] This has led to innumerable errors,
>>> vulnerabilities, and system crashes, which have probably caused a
>>> billion dollars of pain and damage in the last forty years. [...] More
>>> recent programming languages like Spec# have introduced declarations
>>> for non-null references. This is the solution, which I rejected in
>>> 1965.
>>    -- Sir Charles Hoare, Inventor of QuickSort, Turing Award Winner
>
> I suggested to Walter an idea he quite took to: offering the ability of  
> disabling the default constructor. This is because at root any null  
> pointer was a pointer created with its default constructor. The feature  
> has some interesting subtleties to it but is nothing out of the ordinary  
> and the code must be written anyway for typechecking invariant  
> constructors.
>
> That, together with the up-and-coming alias this feature, will allow the  
> creation of the "perfect" NonNull!(T) type constructor (along with many  
> other cool things). I empathize with those who think non-null should be  
> the default, but probably that won't fly with Walter.
>
>
> Andrei

If nullable is the default and NonNull!(T) has no syntactic sugar, I bet it won't be used at all. I know I woudn't, even though I'm one of the biggest advocates of introducing non-nullable types in D.

In my opinion, you should teach novices safe practices first, and dangerous tricks last. Not vice-versa.

If using of nullable types would be easier that non-nullable once, it won't be widely used. The syntax ought to be less verbose and more clear to get an attention.

I hope that this great idea won't get spoiled by broken implementation...