Null references redux

[Steven Schveighoffer]

On Sun, 27 Sep 2009 11:51:27 -0400, bearophile <bearophileHUGS at lycos.com>  
wrote:

> Steven Schveighoffer:
>
>>    Build the non-null requirement into the function signature (note, the
>> requirement is optional, it's still possible to use null references if  
>> you
>> want).
>>
>>    Pros: Easy to implement, Compile-time error, hard to "work around" by
>> putting a dummy value, sometimes no performance hit, most times very
>> little performance hit, allows solution 1 and 2 if you want, runtime
>> errors occur AT THE POINT things went wrong not later.
>>    Cons: Non-zero performance hit (you have to check for null sometimes
>> before assignment!)
>
> To implement it well (and I think it has to be implemented well) it's  
> not so easy to implement. You have to face the problem I've discussed  
> about about multiple object initializations inside various ifs.

I think you are referring to a combination of this solution and flow  
analysis?  I didn't mention that solution, but it is possible.  I agree it  
would be more complicated, but I did say that as a con for flow analysis.

> Also see what downs and I have said regarding arrays of nonnullables.

Yes, arrays of non-nullables will be more cumbersome, I should add that as  
a con.  Thanks.

>
> Among the cons you also have to consider that there's a little more  
> complexity in the language (two different kinds of references, and such  
> things must also be explained in the docs and understood by novice D  
> programmers. It's not a common feature, so they have to learn it).

It's not a common feature, but in practice, one doesn't usually need  
nullable types for most cases, it's only certain cases where it's needed.

For example, no extra docs are needed for:

auto a = new A(); // works, non-nullable is fine

And maybe even for:

A a; // error, must assign non-null  value

because that's a common feature of compilers.

It's similar in my view to shared.  Shared adds a level of complexity that  
needs to be understood if you want to use shared variables, but most of  
the time, your variables are not shared, so no extra thought is required.

> Another thing to add to the cons is that every layer of compile-time  
> constraints you add to a language they also add a little amount of  
> rigidity that has a cost (because you have to add ? and you sometimes  
> may need casts to break such rigidity). Dynamic languages show that  
> constraints have a cost.

The cost needs to be weighed against the cost of the alternatives.  I  
think all the solutions have a cost.  Dynamic languages have a cost too.   
I've been developing in php lately, and I don't know how many times I had  
a bug that I slightly mis-typed a variable name, which still was valid  
code because the language thought I was just declaring a new variable :)   
And to get the IDE to recognize types, I sometimes have to put in a line  
like this:

// uncomment for autocomplete
// x = new ClassType(); printf("Error, please remove line %d\n",  
__LINE__); throw new Exception();

Which I comment out when I'm running, but I uncomment to have the IDE  
recognize that x is a ClassType (for autocomplete).

I think if there was a solution that cost nothing, it would be the clear  
winner.

-Steve