On Friday, 17 January 2014 at 01:42:38 UTC, Andrei Alexandrescu
wrote:
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
I am assuming init will be a property static function. So
essentially we would be removing .init support for classes in
compiler and pushing it out into Object.
I would rather if that is an option an init static function, that
it would be required to have override otherwise it would be too
'magical' for me atleast.
The default can still be null.
