https://issues.dlang.org/show_bug.cgi?id=19916
--- Comment #22 from Dennis <[email protected]> --- (In reply to Manu from comment #18) > There is no world where access to > what can be confirmed to be uninitialised memory is @safe, period. This is just proof by assertion at this point. (https://en.wikipedia.org/wiki/Proof_by_assertion) > Any interaction with uninitialised memory will guarantee unintended > consequences, which could be anything. Counterexample: just print an uninitialized integer. I can predict the consequence pretty well. Also: besides the point. @safe != no bugs and union member access != uninitialized memory. (the discussion got a bit derailed, I suggest continuing in issue 18016 about `= void` and keeping this to union member access) > I don't understand any sentence in this paragraph. Simen argued union access must be unsafe or else this doesn't work: ``` struct S { private int myHandle; // no touchy! @disable this(); this(int x) {myHandle = getValidHandle();} void doSomethingSafe() @trusted {unsafeCfunction(myHandle);} } ``` I say: - it's not necessary, just give S a pointer member - it's not sufficient, __traits(getMember, S, "myHandle") = 0xFFFF; will break it anyway. > You shouldn't slap it on functions, you should minimise the surface area as > much as possible; I agree. Therefore, we shouldn't suddenly reject @safe code that has no chance of corrupting memory, because that invites more use of @trusted increasing the surface area. --
