On Wednesday, 1 February 2017 at 01:52:40 UTC, Adam D. Ruppe
wrote:
On Wednesday, 1 February 2017 at 00:43:39 UTC, bitwise wrote:
Container!int c; // = Container!int() -> can't do this.
Can you live with
Container!int c = Container!int.create();
because D supports that and can force the issue with `@disable
this();` which causes compilation to fail any place where it
isn't explicitly initialized.
I suppose this works, but to be honest, I wouldn't use it.
I really don't feel like I'm asking to "have my cake and eat it
too" by expecting a proper solution for this.
The current behavior doesn't even really make sense.
Example:
struct S {
// this(){}
this(Args...)(auto ref Args args) { writeln("ctor"); }
~this() { writeln("dtor"); }
}
void foo(Args...)(auto ref Args args) { writeln("foo"); }
int main(string[] argv) {
S s;
S s2 = S();
foo();
return 0;
}
outputs:
foo
dtor
dtor
I would expect that I could at least have this() invoked for
's2', but I can't even declare it at all. So while 'S()' looks
like a constructor call, it doesn't call one. Instead, the
current behavior forces explicit initialization of objects,
pointless boilerplate, or unorthodox/unreliable workarounds.
Even more confusingly, the above example prints "foo" but not
"ctor", because calling variadic functions with no arguments is
fine - except for constructors.
Finally, destructors are currently called on objects which were
never constructed. You can't even call what's going on with
structs RAII at this point.
