https://issues.dlang.org/show_bug.cgi?id=22639
Stanislav Blinov <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from Stanislav Blinov <[email protected]> --- I don't see how this is a matter of priority. A copy constructor cannot be ambiguous with field initialization, therefore it shouldn't prohibit it. struct A { A a; // this is impossible... } ...therefore any initialization that takes `A` as first argument must be a constructor call, and the implementation has to figure out which constructor it should be. Given that in the future D would likely also be getting move constructors (i.e. constructors taking rvalue argument of typeof(this) would also be "special"), it'd be advantageous to sort out this problem now, otherwise we stand at risk of magnifying its impact. I think that both them and copy constructors should not interfere with field initialization. Let's not follow C++ further down its constructor hell. The line `A c = A(a, 10);` from the original example should "just work" (c). As should `A c = A(1, 2);`, without requiring the programmer to spell out any other constructors. --
