Copy Constructor DIP

[Andrei Alexandrescu]

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.