[Issue 23868] Compiler-generated opAssign has very high stack frame usage

[d-bugmail at puremagic.com]

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

Walter Bright <bugzilla at digitalmars.com> changed:

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

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

--