https://issues.dlang.org/show_bug.cgi?id=23868

johanengelen@weka.io changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |industry

--

https://issues.dlang.org/show_bug.cgi?id=23868

--- Comment #1 from Dlang Bot <dlang-bot@dlang.rocks> ---
@JohanEngelen created dlang/dmd pull request #15148 "Attempt to fix issue 23868" mentioning this issue:

- Attempt to fix issue 23868

  https://issues.dlang.org/show_bug.cgi?id=23868

  Not sure if this is correct.

https://github.com/dlang/dmd/pull/15148

--

https://issues.dlang.org/show_bug.cgi?id=23868

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|---                         |WONTFIX

--- Comment #2 from Walter Bright <bugzilla@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.

--