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.
