https://issues.dlang.org/show_bug.cgi?id=19916
--- Comment #17 from Dennis <dkor...@live.nl> --- (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! The spec is pretty informal currently. If you have a better interpretation, I'm eager to hear it. So far I've only heard 'things any sane security engineer is wary of'. > For instance, there's C libraries that return opaque handles that may or may > not be actual pointers, and that offer no way to determine if such a handle > is valid or not, and may summon nasal demons if invalid handles are used. 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. > 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? [1] https://github.com/d-gamedev-team/gfm/blob/5b86c52582de04b8b2277a3b257507083ed31cbf/math/gfm/math/vector.d#L26 --