[Issue 15847] It is not an error to call opAssign on an uninitialized object

[via Digitalmars-d-bugs]

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

ag0aep6g at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ag0aep6g at gmail.com

--- Comment #3 from ag0aep6g at gmail.com ---
(In reply to monkeyworks12 from comment #2)
> No, we definitely don't want that. My point is that it is never valid to
> have opAssign called on a void initialized object that has a custom
> opAssign. It works for simple value types, but anything with a custom
> opAssign cannot allow it. Maybe void initialization should be disabled for
> types with custom opAssign.

I don't see how void initialization of types with a custom opAssign is bad
enough to disallow it. You just have to avoid calling the opAssign during
manual initialization, but that's entirely doable.

----
/* ... struct Test as in your code ... */
Test t = void;
t.n = int.init; /* manual initialization without calling opAssign */
t = 0; /* no problem */
----

A generic version (could also use memcpy or similar):
----
Test tinit = Test.init;
* cast(void[Test.sizeof]*) &t = * cast(void[Test.sizeof]*) &tinit;
----

This is similar to how `cast(void*) someClassObject` can do something
surprising when it calls a custom opCast. But casts and void initialization are
dangerous, unsafe features to be used with much care. And a programmer who uses
them is expected to be aware of opCast and opAssign.

--