Null references redux

[Andrei Alexandrescu]

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Walter Bright wrote:
>>> The problem with non-nullable references is what do they default to? 
>>> Some "nan" object? When you use a "nan" object, what should it do? 
>>> Throw an exception?
>>
>> This is the mistake. There would no way to default initialize a 
>> non-null object. I'm surprised you are still saying this, because we 
>> discussed how NonNull!T could be implemented by disabling its default 
>> constructor.
> 
> Sure, so the user just provides "0" as the argument to the non-default 
> constructor. Or he writes:
> 
>     C c = c_empty;
> 
> using c_empty as his placeholder for an empty object. Now, what happens 
> with:
> 
>     c.foo();
> 
> ? Should c_empty throw an exception?

The problem is you keep on insisting on one case "I have a non-null 
reference that I don't have an initializer for, but the compiler forces 
me to find one, so I'll just throw a crappy value in." This focus on one 
situation comes straight with your admitted bad habit of defining 
variables in one place and initializing in another. The situation you 
need to open a curious eye on is "I have a reference that's never 
supposed to be null, but I forgot about initializing it and the compiler 
silently put a useless null in it." The simplest case is what _every_ D 
beginner has done:

T x;
x.fun();

to witness a crash. Why the hell does that crash? It did work when T was 
a struct. (Also this damns generic code to hell.)

So again: focus on the situation when people forget to initialize 
references that are never supposed to be null.

That has happened to me, and I'm supposed to know about this stuff. And 
one thing you don't understand is that on Linux, access violations are 
much more difficult to figure than others. On a computing cluster it 
gets one order of magnitude more difficult. So spare me of your Windows 
setup that launches your debugger on the line of the crash. For better 
or worse, many don't have that. People sometimes have problems that you 
don't have, and you need to put yourself in their shoes.

> To take this a little farther, 
> suppose I wish to create an array of C that I will partially fill with 
> valid data, and leave some empty slots. Those empty slots I stuff with 
> c_empty, to avoid having nulls. What is c_empty's proper behavior if I 
> mistakenly try to access its members?

You make an array of nullable references. Again you confuse having 
non-null as a default with having non-null as the only option.

> Forcing the user to provide an initializer does not solve the problem. 
> The crucial point is the problem is *not* the seg fault, the seg fault 
> is the symptom. The problem is the user has not set the object to a 
> value that his program's logic requires.
> 
> 
> I am also perfectly happy with NonNull being a type constructor, to be 
> used where appropriate. My disagreement is with the notion that null 
> references should be eliminated at the language level.

Null references shouldn't be eliminated from the language. They just 
should NOT be the default. I guess I'm going to say that until you tune 
on my station.


Andrei