Null references redux

Yigal Chripun yigal100 at gmail.com
Sun Sep 27 09:28:42 PDT 2009


On 27/09/2009 17:51, bearophile 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. Also
> see what downs and I have said regarding arrays of nonnullables.

I don't accept this argument about nested if statements. D has a 
procedural "if" statement. Of course it doesn't mesh together with 
non-nullable references, you're trying to fit a square peg in a round hole.
the solution is to write a more functional style code. if D ever 
implements true tuples that would be a perfect use case for them.

(T1 t1, T2 t2) = init();
t1.foo;
t2.bar;

>
> 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).

that's true. Not only this needs to be taught and pointed out to newbies 
it should also be encouraged as the D way so that it will be used by 
default.
>
> 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.
>
> Bye, bearophile




More information about the Digitalmars-d mailing list