Null references redux

Nick Sabalausky a at a.a
Tue Sep 29 16:45:09 PDT 2009


"Jeremie Pelletier" <jeremiep at gmail.com> wrote in message 
news:h9tv1s$do5$2 at digitalmars.com...
> Rainer Deyke wrote:
>> Jeremie Pelletier wrote:
>>> struct NonNull(C) if(is(C == class)) {
>>>     C ref;
>>>     invariant() { assert(ref !is null); }
>>>     T opDot() { return ref; }
>>> }
>>
>> This only catches null errors at runtime.  The whole point of a non-null
>> type is to catch null errors at compile time.
>>
>
> Thats what flow analysis is for, since these are mostly uninitialized 
> variables rather than null ones.
>
> If variables are properly initialized, you'll never get null where you 
> don't expect it, and those are checked at compile time too

--------------------------------------
Foo mightReturnSometing()
{
    if(someRuntimeCondition)
        return someFoo;
    else
        return null;
}

void doSomethingWithFoo(Foo f)
{
  f.bar();
  f.baz();
  // etc
}

Foo f = mightReturnSometing();
doSomethingWithFoo(f);
--------------------------------------

That sort of scenario is not uncommon, and is often not particularly 
obvious. How is flow analysis going help with it at compile-time? It can't. 
But non-nullables can.





More information about the Digitalmars-d mailing list