Non-null objects, the Null Object pattern, and T.init

[Andrei Alexandrescu]

Walter and I were talking today about the null pointer issue and he had 
the following idea.

One common idiom to replace null pointer exceptions with milder 
reproducible errors is the null object pattern, i.e. there is one object 
that is used in lieu of the null reference to initialize all otherwise 
uninitialized references. In D that would translate naturally to:

class Widget
{
     private int x;
     private Widget parent;
     this(int y) { x = y; }
     ...
     // Here's the interesting part
     static Widget init = new Widget(42);
}

Currently the last line doesn't compile, but we can make it work if the 
respective constructor is callable during compilation. The compiler will 
allocate a static buffer for the "new"ed Widget object and will make 
init point there.

Whenever a Widget is to be default-initialized, it will point to 
Widget.init (i.e. it won't be null). This beautifully extends the 
language because currently (with no init definition) Widget.init is null.

So the init Widget will satisfy:

assert(x == 42 && parent is Widget.init);

Further avenues are opened by thinking what happens if e.g. init is 
private or @disable-d.

Thoughts?


Andrei