On Thu, 12 Jul 2018 at 18:25, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@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.
