[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

Jonathan M Davis <issues.dlang at jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang at jmdavisProg.co
                   |                            |m
           Hardware|x86_64                      |All
                 OS|Linux                       |All

--- Comment #10 from Jonathan M Davis <issues.dlang at jmdavisProg.com> ---
This really needs to be improved so that we're not just creating an inout copy
constructor when an implicit copy constructor needs to be generated. It simply
does not work when the member variable with a copy constructor has a different
signature, and with all of the situations where the programmer has _zero_
control over the type with the implicit constructor (e.g. it's a Voldemort
range type from a function in Phobos or some other library), we really need to
be able to rely on implicit copy constructors actually working with other
signatures.

At this point, it's turning out to be shockingly difficult to add a copy
constructor to a type that's core to the code base that I work on at work, and
the fact that implicit constructor generation is so simplistic (and therefore
fails so easily) is a major contributing factor. And right now, I'm forced to
use an inout constructor even though that's _really_ not what I should be using
in this case, because the implicit constructor generation doesn't work with
anything else.

IMHO, we really need to look at having the compiler generate the full set of
copy constructors that are necessary to work with the member variables and not
just a single one that tries to work in general but really doesn't. There are
just too many situations where you don't control the code with the implicit
constructor and therefore can't make it do the right thing, whereas in almost
all cases like that it should be very possible for the compiler to generate a
set of copy constructors that actually work - but instead, it just punts on the
issue and tries a single inout copy constructor.

This isn't the only issue that causes major problems with copy constructors,
but it's a significant one.

--