Non-null objects, the Null Object pattern, and T.init
Michel Fortin
michel.fortin at michelf.ca
Fri Jan 17 07:05:12 PST 2014
On 2014-01-17 01:42:37 +0000, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> said:
> Further avenues are opened by thinking what happens if e.g. init is
> private or @disable-d.
>
> Thoughts?
Some more thoughts.
Couldn't we just add a class declaration attribute that'd say that by
default this type is not-null? For instance:
// references to A are not-null by default
@notnull class A {}
// references to B are not-null too (inherited)
class B : A {}
Then you have two types:
A // not-null reference to A.
A? // nullable reference to A.
Use it like this:
A a; // error: cannot be null, default initialization not allowed
A? a; // default-initialized to null
void test1(A a) // param a cannot be null
{
a.foo(); // fine
}
void test2(A? a) // param a can be null
{
a.foo(); // error: param a could be null
if (a)
a.foo(); // param a cannot be null, allowed
}
void test3(A? a) // param a can be null
{
A aa = a; // error: param a could be null, can't init to not-null type
if (a)
aa = a; // param a cannot be null, allowed
}
This is basically what everyone would wish for a not-null type to do.
The syntax is clean and the control flow forces you to check for null
before use. Misuses result in a compile-time error.
--
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca
More information about the Digitalmars-d
mailing list