On 7/12/18 10:05 PM, Manu wrote:
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.
Affirmative. The DIP needs to specify how assignment is handled if no
opAssign is present but a copy ctor is present. Thanks!
