[Issue 20876] generated constructor always inout regardless of ability of fields to use inout

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=20876

--- Comment #18 from RazvanN <razvan.nitu1305 at gmail.com> ---
(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.

--