On Monday, 20 January 2014 at 00:44:21 UTC, Michel Fortin wrote:
On 2014-01-19 20:07:40 +0000, Timon Gehr <timon.g...@gmx.ch>
said:
On 01/19/2014 01:03 PM, Michel Fortin wrote:
Actually, 'A?' would implicitly convert to 'A' where the
compiler can
prove control flow prevents its value from being null.
I think the type should be upgraded. i.e.:
So you can
dereference it in a branch that checked for null:
class A { int i; void foo(); }
void bar(A a); // non-nullable parameter
void test(A? a, A? a2)
{
a.i++; // error, 'a' might be null
a.foo(); // error, 'a' might be null
bar(a); // error, 'a' might be null
if (a)
{
static assert(is(typeof(a)==A));
a.i++; // valid [...]
a.foo(); // valid [...]
bar(a); // valid [...]
}
}
That's one way to do it. Note that this means you can't assign
null to 'a' inside the 'if' branch. But I wouldn't worry too
much about that. I think it'd make a good first implementation.
What I expect from a not-null feature is that it starts by
being over-restrictive and with time, as the control flow
analysis evolves, unnecessary restrictions would be lifted.
That's similar to how CTFE and purity became what they are
today.
I don't see the point of intruducing a new syntax for nullable,
when D typesystem is already powerful enough to provide it as lib.
