https://issues.dlang.org/show_bug.cgi?id=19916
--- Comment #20 from Manu <[email protected]> --- > Otherwise, when the focus is on memory corruption, there's more (perceived) > wiggle room. We're tempted to allow anything that doesn't lead to memory > corruption in practice, even if has undefined behavior. That quickly gets > messy. T x = void; // <- DOES lead to memory corruption; it's effectively an explicit statement to do memory corruption. How could a more explicit violation of @safe exist, no matter how you squint and interpret it? > (In reply to Manu from comment #18) > > 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. > > You might want to argue your position in > <https://github.com/dlang/dlang.org/pull/2260>. It's an open PR by Walter > where he does exactly what you oppose here: he wants to explicitly allow > accessing uninitialized memory in @safe code (unless it involves pointers). That PR doesn't appear to have anything to do with @safe? --
