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