Null references redux

[Jeremie Pelletier]

Andrei Alexandrescu wrote:
> Walter Bright wrote:
>> Denis Koroskin wrote:
>>  > On Sat, 26 Sep 2009 22:30:58 +0400, Walter Bright
>>  > <newshound1 at digitalmars.com> wrote:
>>  >> D has borrowed ideas from many different languages. The trick is to
>>  >> take the good stuff and avoid their mistakes <g>.
>>  >
>>  > How about this one:
>>  > 
>> http://sadekdrobi.com/2008/12/22/null-references-the-billion-dollar-mistake/ 
>>
>>  >
>>  >
>>  > :)
>>
>> I think he's wrong.
>>
>> Getting rid of null references is like solving the problem of dead 
>> canaries in the coal mines by replacing them with stuffed toys.
>>
>> It all depends on what you prefer a program to do when it encounters a 
>> program bug:
>>
>> 1. Immediately stop and produce an indication that the program failed
>>
>> 2. Soldier on and silently produce garbage output
>>
>> I prefer (1).
>>
>> Consider the humble int. There is no invalid value such that 
>> referencing the invalid value will cause a seg fault. One case is an 
>> uninitialized int is set to garbage, and erratic results follow. 
>> Another is that (in D) ints are default initialized to 0. 0 may or may 
>> not be what the logic of the program requires, and if it isn't, again, 
>> silently bad results follow.
>>
>> Consider also the NaN value that floats are default initialized to. 
>> This has the nice characteristic of you know your results are bad if 
>> they are NaN. But it has the bad characteristic that you don't know 
>> where the NaN came from. Don corrected this by submitting a patch that 
>> enables the program to throw an exception upon trying to use a NaN. 
>> Then, you know exactly where your program went wrong.
>>
>> It is exactly analogous to a null pointer exception. And it's darned 
>> useful.
> 
> My assessment: the chances of convincing Walter he's wrong are quite 
> slim... Having a rationale for being wrong is very hard to overcome.
> 
> Andrei

I actually side with Walter here. I much prefer my programs to crash on 
using a null reference and fix the issue than add runtime overhead that 
does the same thing. In most cases a simple backtrace is enough to 
pinpoint the location of the bug.

Null references are useful to implement optional arguments without any 
overhead by an Optional!T wrapper. If you disallow null references what 
would "Object foo;" initialize to then?

Jeremie