https://issues.dlang.org/show_bug.cgi?id=23868
Walter Bright <bugzi...@digitalmars.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |bugzi...@digitalmars.com
Resolution|--- |WONTFIX
--- Comment #2 from Walter Bright <bugzi...@digitalmars.com> ---
(In reply to johanengelen from comment #0)
> I believe this implemention of opAssign would solve the problem, as I am 99%
> sure that the semantic difference (dtor call before the assignment) is
> allowed by the spec:
> ```
> ref @system S opAssign(ref S p) return // note I added `ref`
> {
> this.S.~this();
> this = p;
> return this;
> }
> ```
This does not work in the general case. The canonical example is if S is a
ref-counting wrapper around some other object. If the ref count is 1, and p
wraps the same object as `this`, then the wrapped object will get deleted
before it gets copied.
Adding:
@disable ref S opAssign(ref S);
will disable the automatic generation of the assignment operator for S. Note
use of `ref` for both the return and the parameter.
I'm going to close this as WONTFIX because the existing algorithm is the
pedantically correct one, writing a custom one will override the standard
algorithm, and the generating the standard one can be disabled with @disable.
Another solution would be to make `arr` a pointer to the data rather than the
data itself. Which solution to pick depends, of course, on the application.
--
