Copy Constructor DIP

[Andrei Alexandrescu]

On 7/12/18 6:37 PM, Manu wrote:
> On Thu, 12 Jul 2018 at 07:15, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d at 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