[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

monkeywork...@hotmail.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from monkeywork...@hotmail.com ---
"It simply isn't possible to detect that the variable is void-initialized in
the general case."

While it could be done reasonably well with flow control analysis, I agree that
it's a lot of work for a small return. Thus it makes more sense to disallow
void initialization for types with a custom opAssign.

"But note that void-initialization is already @system..."

Okay, I forgot this point, and it does mitigate my concerns. I will close this
bug.

--

[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

--- Comment #4 from Marc Schütz  ---
It simply isn't possible to detect that the variable is void-initialized in the
general case. Other languages can do that by way of their design (e.g. Rust,
which does extensive data flow analysis, or languages that have a notion of
typestate), but D can't do that. At best, the compiler could try to detect
trivial cases like in your example. But note that void-initialization is
already @system (at least if references are involved), so as ag0aep6g says, the
user is responsible for using it correctly.

--

[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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #3 from ag0ae...@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]*)  = * cast(void[Test.sizeof]*) 


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.

--

[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

Marc Schütz  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schue...@gmx.net
 Resolution|--- |INVALID

--- Comment #1 from Marc Schütz  ---
Your test cannot work reliably, but...

It is not a bug that opAssign() is called here. Using void initialization
doesn't mean "please turn the first assignment into a construction". That
wouldn't work in the general case. It means "don't initialize this variable,
I'll take care of it myself".

However, what you wrote on Github - that the assignment operator for the out
parameter isn't called - is still true. I've filed it here:
https://issues.dlang.org/show_bug.cgi?id=15848

--