Null references redux

[Yigal Chripun]

On 27/09/2009 00:59, Jeremie Pelletier wrote:
> Jarrett Billingsley wrote:
>> On Sat, Sep 26, 2009 at 5:29 PM, Jeremie Pelletier
>> <jeremiep at gmail.com> wrote:
>>
>>> 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.
>>
>> There is NO RUNTIME OVERHEAD in implementing nonnull reference types.
>> None. It's handled entirely by the type system. Can we please move
>> past this?
>>
>>> 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?
>>
>> It wouldn't. The compiler wouldn't allow it. It would force you to
>> initialize it. That is the entire point of nonnull references.
>
> How would you do this then?
>
> void foo(int a) {
> Object foo;
> if(a == 1) foo = new Object1;
> else if(a == 2) foo = Object2;
> else foo = Object3;
> foo.doSomething();
> }
>
> The compiler would just die on the first line of the method where foo is
> null.
>
> What about "int a;" should this throw an error too? Or "float f;".
>
> What about standard pointers? I can think of so many algorithms who rely
> on pointers possibly being null.
>
> Maybe this could be a case to add in SafeD but leave out in standard D.
> I wouldn't want a nonnull reference type, I use nullables just too often.

with current D syntax this can be implemented as:

void foo(int a) {
   Object foo = (a == 1) ? new Object1
              : (a == 2) ? Object2
              : Object3;
   foo.doSomething();
}

The above agrees also with what Denis said about possible uninitialized 
variable bugs.

in D "if" is the same as in C - a procedural statement.
I personally think that it should be an expression like in FP languages 
which is safer.

to reinforce what others have said already:
1) non-null references *by default* does not affect nullable references 
in any way and does not add any overhead. The idea is to make the 
*default* the *safer* option which is one of the primary goals of this 
language.
2) there is no default value for non-nullable references. you must 
initialize it to a correct, logical value *always*. If you resort to 
some "default" value you are doing something wrong.

btw, C++ references implement this idea already. functions that return a 
reference will throw an exception on error (Walter's canary) while the 
same function that returns a pointer will usually just return null on 
error.

segfaults are *NOT* a good mechanism to handle errors. An exception 
trace gives you a whole lot more information about what went wrong and 
where compared to a segfault.