Copy Constructor DIP

[Manu]

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.