https://issues.dlang.org/show_bug.cgi?id=20876
--- Comment #18 from RazvanN <[email protected]> --- (In reply to Walter Bright from comment #16) > If we add `const` to the first copy constructor: > > struct S { > this(const ref S) { } > } > > it compiles without error. > > It seems like a simple solution would be: > > 1. if all fields take a const argument, then generate a const copy > constructor > > 2. if all fields take an immutable argument, then generate an immutable copy > constructor > > 3. otherwise, generate a mutable copy constructor Why are we imposing random rules of copy constructor generation? As I see it, each copy constructor from an overload set of copy constructors defines how that object performs a copy for a given qualifier pair. Whenever that object is copied it should respect the rules defined in its copy constructors. Why don't we propagate that when the object is a field of another struct? It seems like the most natural thing to do and it is what the majority of users would expect. Moreover, it leads to natural composability. Trying to elide the generation of copy constructors only leads to confusing situations (see the inout(inout) copy constructor that is currently being generated). When I wrote the copy constructor DIP the copy constructor generation was done according to what https://github.com/dlang/dmd/pull/16429 implements. However, you rejected it not for any objective reason, but because you thought this is too complex and proposed the inout(inout) alternative. Now people have been complaining about inout(inout) copy constructor generation, which is completely useless, and asked for the natural generation of copy constructors and yet without a single argument to show why this is not a good strategy (simply stated "I am not sure this PR is the best solution") you propose a different solution which also doesn't actually fix the issue. I think that you should come up with a concrete example to showcase why generating multiple copy constructors is a bad strategy. If it's compile time performance that you are worried about, I don't think that that is something we should actually fear - I expect that that's not going to be a problem. However, even if we a pay a small compile time price, we strike a major win on the front of user experience. --
