Copy Constructor DIP

[Andrei Alexandrescu]

On 7/12/18 10:05 PM, Manu wrote:
> On Thu, 12 Jul 2018 at 18:25, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>>
>> On 7/12/18 4:29 PM, Manu wrote:
>>> Being able to implement them both independently is*occasionally*
>>> useful, but 95% of the time, destruct + copy-construct is an equally
>>> efficient implementation for assignment. I'd suggest that this
>>> destruct+copy-construct pattern is a perfectly good substitute for
>>> assignment in most cases, and maybe the compiler should deploy the
>>> pattern as an implicit copy constructor in lieu of an explicit one?
>>> So, if the user specifies a complex copy constructor, but no
>>> assignment operator (which just blits on copy), then they've almost
>>> certainly introduced a bug on copying! Perhaps the compiler should
>>> automatically emit an assignment operator implemented as above in
>>> presence of a (suite of? [const/immutable/etc permutations]) 'complex'
>>> copy constructor?
>>
>> Not the charter of the current DIP.
> 
> In a post-blit world, with no opAssign specified, postblit will call
> for copy construction AND for assignment, thereby assignment is always
> correct.
> Once postblit is swapped for a copy-constructor, absence of opAssign
> will result in invalid behaviour on assignment.
> 
> Introduction of copy constructor breaks default assignment, it needs
> to address it somehow. I think my suggestion is the only practical
> solution.

Affirmative. The DIP needs to specify how assignment is handled if no 
opAssign is present but a copy ctor is present. Thanks!