Null references redux

[Jeremie Pelletier]

Yigal Chripun wrote:
> 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.

This is something for the runtime or the debugger to deal with. My 
runtime converts access violations on windows or segfaults on linux into 
exception objects, which unwind all the way down to main where it 
catches into the unhandled exception handler (or crash handler) and I 
get a neat popup with a "hello, your program crashed at this point, here 
is a backtrace with resolved symbols and filenames along with current 
registers and loaded modules, would you like a cup of coffee while you 
solve the problem?". I sent that crash handler to D.announce last week too.

The compiler won't be able to enforce *every* nonnull reference and 
segfaults are bound to happen, especially with casting. While it may 
prevent most of them, any good programmer would too, I don't remember 
the last time I had a segfault on a null reference actually.

I can see what the point is with nonnull references, but I can also see 
its not a bulletproof solution. ie "Object foo = cast(Object)null;" 
would easily bypass the nonnull enforcement, resulting in a segfault the 
system is trying to avoid.

What about function parameters, a lot of parameters are optional 
references, which are tested and then used into functions whose 
parameters aren't optional. It would result in a lot of casts, something 
that could easily confuse people and easily generate segfaults.

Alls I'm saying is, nonnull references would just take the issue from 
one place to another. Like Walter said, you can put a gas mask to ignore 
the room full of toxic gas, but that doesn't solve the gas problem in 
itself, you're just denyinng it exists. Then someday you forget about 
it, remove the mask, and suffocate.

Jeremie