On Fri, 23 Oct 2009 19:40:33 +0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Denis Koroskin wrote:
On Fri, 23 Oct 2009 18:46:47 +0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Don wrote:
Bartosz Milewski wrote:
Andrei Alexandrescu Wrote:
this() { myCount = count++; } // ERROR
It's worse than that. Try this:
struct foo {
this(int dummy = 0) { writeln("Default constructor");}
}
foo x = foo();
Nothing gets printed. If default constructors are disallowed, so
should constructors with all parameters defaulted.
Ouch.
It's because it's interpreting foo() as a struct literal.
If a struct has any constructors, struct literals should be disabled.
http://d.puremagic.com/issues/show_bug.cgi?id=3438
The more I think of it, the more imperious it becomes that we allow
default constructors that execute code. The main question is what to
do about .init.
Andrei
I'd suggest ditching it and enforce explicit member initialization
(unless a variable is nullable). This will also remove a lot of bloat
from executables.
I don't understand. The problem right now is that even of all fields are
explicitly intialized, e.g.
struct A {
Widget x = null;
double d = 0;
int i = -1;
}
there is still no ability to execute code upon initialization, e.g.
force A to contain a non-null Widget.
Andrei
Yes, I was talking about a different scheme, where default ctors are
allowed. They aren't allowed now but we are talking about things we can
change/improve, right?
I mean there is no _real_ need for T.init, just malloc()'ate some memory
and call the __ctor on it. Struct members default values would be
converted into runtime initialization expressions like this:
struct A
{
this(Args)(Args args) // may be an empty set of arguments
{
// the following lines are inserted automatically
x = null;
d = 0;
i = -1;
// user-defined code follows
i = 42;
}
Widget x = null;
double d = 0;
int i = -1;
}
Optimization pass would eliminate double initialization (in the case about
i would be initialized straight to 42)
