Copy Constructor DIP

[Manu]

On Fri, 13 Jul 2018 at 07:40, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 7/12/18 11:01 PM, Manu wrote:
> > What existing code are you changing the semantics of?
> > It's still not clear to me how accepting `this(ref T)` as a magic
> > signature that is a copy constructor can break existing code?
> > Is it the unlikely^^2 case that the function exists somewhere and
> > doesn't perform copy construction?
> >    1. the function is highly unlikely to exist because postblit; it's a
> > meaningless function to write. are there any known instances of that
> > signature in the wild?
> >    2. if the function does exist, it's highly unlikely that it doesn't
> > perform a valid copy construction; what else could it possibly do?
> >    3. remaining cases are broken by this DIP, but they are probably
> > crazy and deserve to be deprecated!
> >
> > Is there any reasonable existing use of the signature that would be
> > legitimately broken by being invoked implicitly?
> > I feel like there's something that I'm missing... but if there's not,
> > then just change the semantic.
> >
> > I reason; copy construction is something so fundamental. It will be
> > written by basically every programmer with relative high frequently,
> > and adding awkward syntax or weird language baggage to the concept
> > feels like a very poor choice.
> > By contrast, if there's 1 user out there who used the copy-constructor
> > signature to do some weird thing other than copy construction, and
> > their code is broken by this change, his use case does not balance the
> > imposition applied to every implementation of copy constructor forever
> > from this time forward.
> > This is so much more important than that, it's extremely fundamental
> > language stuff, and needs to be as friction-less as possible, and it
> > should certainly not reek of legacy drama.
>
> Noted. So in summary you would be okay with changing semantics of
> existing code, under the intuition that the change is unlikely to be
> destructive anyway.

Yes, I think this is too important and fundamental to lug historical
baggage along with it for the rest of time.

That said, I'm firmly in favour of @implicit, but the terms of
introduction here are not satisfying.
If we're going to add yet another attribute, I want to know it's a
really good attribute. Adding a whole new attribute just as a marker
in this case, and no clear sign that it may or may not be developed
into an obvious extension of the concept (and what that looks like) is
not satisfactory grounds to introduce a new attribute.
I don't understand your objection to this point. I feel like you of
all people should be arguing this case.

If the DIP specifies introduction of an attribute, then I can't see
how there's not a dependency on specification of the attribute. (That
doesn't necessarily mean it must be implemented all at once, but I
feel like the spec/intent should be presented up-front)