On Thu, 12 Jul 2018 at 07:15, Andrei Alexandrescu via Digitalmars-d <email@example.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.