``` struct Bar { this(const ref Bar o) {} string a; uint b; } void main () { // foo.d(11): Error: struct Bar has constructors, cannot use { initializers }, use Bar( initializers ) instead Bar b = { a: "Hello", b: 42 }; // foo.d(12): Error: copy constructor foo.Bar.this(ref const(Bar) o) is not callable using argument types (string\ , int) // foo.d(12): cannot pass rvalue argument "Hello" of type string to parameter ref const(Bar) o Bar c = Bar("Hello", 42); } ``` Expected result: This should compile. It should also work if the constructor is `@disable`d.
This is not related to copy constructors: struct K { int a; string b; this(int, int, int) {} } void main() { K s = K(7, "gigi"); } It seems that once you define a constructor, you are not able to use the default constructor.
I can't find anything in the spec regarding this aspect.
It's always been the case that implementing opCall or a constructor disables struct literals and initializers (except the default initializer T()), but it's not currently in the spec (I'm sure it was at one time). From TDPL 7.1.3.1: "The presence of at least one constructor disables all of the field-oriented constructors discussed above..." And by "field-oriented constructors", he's referring to literals and initializers. The example: ``` struct Test { double a = 0.4; double b; this(double b) { this.b = b; } } auto t1 = Test(1.1, 1.2); // Error // No constructor matches Test(double, double) static Test t2 = {0.0, 1.0}; // Error // No constructor matches Test(double, double); ``` The spec needs to be updated.
> It's always been the case that implementing opCall or a constructor disables struct literals and initializers `opCall` does not disable literals. And it technically *hides* constructors, I'm sure there are some convoluted way to show it. > This is not related to copy constructors: [...] I'm well aware of the disappearance of default ctors in the presence of a single definition. While I would like for us to have a way to control it, a la "this() = default" (from C++), copy ctors are not *regular* ctors, and I don't think they should disable the default constructors.
(In reply to Mathias LANG from comment #4) > > It's always been the case that implementing opCall or a constructor disables struct literals and initializers > > `opCall` does not disable literals. And it technically *hides* constructors, > I'm sure there are some convoluted way to show it. > > > This is not related to copy constructors: [...] > > I'm well aware of the disappearance of default ctors in the presence of a > single definition. While I would like for us to have a way to control it, a > la "this() = default" (from C++), copy ctors are not *regular* ctors, and I > don't think they should disable the default constructors. Actually, copy constructors behave exactly as normal constructors, except that they may be called implicitly in some situations.
@RazvanN7 created dlang/dmd pull request #12132 "Fix Issues 20695, 21547 - CpCtor disables default construction + Struct initializers are disabled wrongfully" fixing this issue: - Fix Issues 20695, 21547 - CpCtor disables default construction + Struct initializers are disabled wrongfully https://github.com/dlang/dmd/pull/12132
dlang/dmd pull request #12132 "Fix Issues 20695, 21547 - CpCtor disables default construction + Struct initializers are disabled wrongfully" was merged into master: - b61df05dd3d5d9792452c496d07fe04f2df12993 by RazvanN7: Fix Issues 20695, 21547 - CpCtor disables default construction + Struct initializers are disabled wrongfully https://github.com/dlang/dmd/pull/12132