https://issues.dlang.org/show_bug.cgi?id=19916
--- Comment #18 from Manu <[email protected]> --- (In reply to Dennis from comment #17) > (In reply to Simen Kjaeraas from comment #16) > > There's code that simply cannot be @trusted under Dennis' @safe regime that > > would be perfectly safe without void initialization and union member access. > > If you don't agree with the 'insufficient to corrupt memory' regime, please > propose a new one! Uninitialised memory is ALREADY CORRUPTED. There is no world where access to what can be confirmed to be uninitialised memory is @safe, period. Any interaction with uninitialised memory will guarantee unintended consequences, which could be anything. It's very simple; if you're going to use unions, or uninitialised memory, then do so carefully, and @trusted that block of code. > Then store that handle as a void* or make it absolutely inaccessible from > the outside. Disabling @safe union access of non-pointers is neither > necessary nor sufficient to prevent invalid handles to be passed to your C > library. The constraint 'I only want integer members in my struct with > @trusted memory sensitive data' is completely arbitrary and only exists in > an attempt to validate this issue. I don't understand any sentence in this paragraph. > > Also, unions are really a low-level trick that is very rarely used. > > How do you know? I use them in @safe code. GFM (which is downloaded 31739 > times at the time of writing) uses them for their vectors [1] among other > things. Any formerly safe game using GFM vectors needlessly breaks! And the > quick fix will be to slap @trusted labels in every function where vector > members are accessed. How is that for memory safety? It's an explicit statement that you considered and correctly handled the issues of interacting with unsafe low-level machinery. You shouldn't slap it on functions, you should minimise the surface area as much as possible; perhaps higher-level functions should access the unsafe shit through small helpers. Maybe use a tagged-union helper, etc. --
