Copy Constructor DIP

[Manu]

On Thu, 12 Jul 2018 at 19:15, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 7/12/18 6:34 PM, Manu wrote:
> > On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via Digitalmars-d
> > <digitalmars-d at puremagic.com> wrote:
> >>
> >> On 07/11/2018 11:11 AM, Atila Neves wrote:
> >>> On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote:
> >>>>> But there's a super explicit `@implicit` thing written right there...
> >>>>> so should we expect that an *explicit* call to the copy constructor
> >>>>> is not allowed? Or maybe it is allowed and `@implicit` is a lie?
> >>>>
> >>>> The @implicit is there to point out that you cannot call that method
> >>>> explicitly; it gets called for you implicitly when you construct an
> >>>> object
> >>>> as a copy of another object.
> >>>
> >>> How is this different from other types of constructors or destructors?
> >>
> >> The main difference is that the compiler may insert calls to it implicitly.
> >
> > You mean like ~this(), and op[Anything](), and front() and popFront()
> > and empty()?
> > I don't think we need this attribute.
>
> I mentioned this, and patiently will mention it again: we need to
> introduce the attribute so as to avoid silently changing the semantics
> of existing code.

Take this reply while assuming a no- at implicit world, which I think is
still a reasonable option (although I support introduction of
@implicit in my other recent replies):

Don't be condescending. I asked, and I will "patiently" ask again,

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.