On 7/12/18 6:37 PM, Manu wrote:
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);
Not if the object has immutable fields, is immutable itself, is assigned
from an immutable object and has non-immutable indirections, etc.
One issue the DIP is addressing carefully is copying across qualifier
combinations. It also emphasizes how the current postblit fails at that.
We should consider fabricating an implicit assignment operator in the
presence of an elaborate copy constructor.
Not in this DIP.
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.
Exploring is of course welcome. Are you talking about the D language?
Assignment never did just blit, and this DIP does not propose that.
Andrei
