On Thu, 12 Jul 2018 at 07:15, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
> On 07/12/2018 09:49 AM, Atila Neves wrote:
> > On Thursday, 12 July 2018 at 06:54:37 UTC, RazvanN wrote:
> >
> >> [...]
> >
> >> If by "come in pairs" you mean that you can define them both, then yes,
> >> that is the case. Will add a paragraph in the DIP to specify this.
> >>
> >> You mentioned that it's terrible that the assignment operator
> >> and the copy constructor come in pairs. Why is that? Would you rather
> >> have a copy constructor that is used also as an assignment operator?
> >
> > Because, like in C++, now you have to implement both and make sure they
> > do the same thing. Boilerplaty and a recipe for disaster.
> >
> > Atila
> There's no meaningful way to avoid that. The two operations are
> fundamentally different, are typechecked differently, and actually are
> different in the presence of qualifiers on fields.
> Introspection is a key helper here compared to C++.

As I've said elsewhere, opAssign() can be fabricated by:
  this.destroy(); emplace(&this, copyFrom);

We should consider fabricating an implicit assignment operator in the
presence of an elaborate copy constructor.
As you say, this interacts with qualifiers... I don't think it's
trivial, but I think it should be explored. Otherwise whenever anyone
forgets to implement an assignment operator, it'll just blit, which is
almost certainly incorrect.

Reply via email to