Null references redux

Jarrett Billingsley jarrett.billingsley at gmail.com
Sun Sep 27 13:04:51 PDT 2009


On Sun, Sep 27, 2009 at 3:42 PM, Jeremie Pelletier <jeremiep at gmail.com> wrote:
> Jarrett Billingsley wrote:
>> Nonnull types do not create implicit null checks. Nonnull types DO NOT
>> need to be checked. And nullable types WOULD force explicit null
>> checks.
>
> Forcing checks on nullables is just as bad, not all nullables need to be
> checked every time they're used.

You don't get it, do you. If you have a reference that doesn't need to
be checked every time it's used, you make it a *nonnull reference*.
You *only* use nullable variables for references where the nullness of
the reference should change the program logic.

And if you're talking about things like:

Foo? x = someFunc();

if(x is null)
{
    // one path
}
else
{
    // use x here
}

and you're expecting the "use x here" clause to force you to do
(cast(Foo)x) every time you want to use x? That's not the case. The
condition of the if has *proven* x to be nonnull in the else clause,
so no null checks - at compile time or at runtime - have to be
performed there, nor does it have to be cast to a nonnull reference.

And if you have a nullable reference that you know is not null for the
rest of the function? Just put "assert(x !is null)" and everything
that follows will assume it's not null.

>> hash_t foo(Object o) { return o.toHash(); }
>> foo(null); // bamf, I just killed your function.
>>
>> Forcing initialization of locals does NOT solve all the problems that
>> nonnull references would.
>
> You didn't kill my function, you shot yourself in the foot. Something
> trivial to debug.

You're dodging. You claim that forcing variable initialization solves
the same problem that nonnull references do. It doesn't.



More information about the Digitalmars-d mailing list