https://issues.dlang.org/show_bug.cgi?id=18016
Steven Schveighoffer <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Steven Schveighoffer <[email protected]> --- I personally thought this was not required for memory safety -- since @safe is not allowed to break the type system, having data that is garbage isn't going to corrupt memory, as long as it's not a reference. Note that =void is not allowed in @safe already for reference types (even though the spec doesn't outline that rule). I'd want Walter's opinion on this. I thought @safe was specifically for memory safety, and not preventing all undefined behavior. But the way the spec is currently written, void initialization should be disallowed. My vote would be to relax the undefined behavior of =void for value types (for reference types or types that contain references, keep it UB). (In reply to RazvanN from comment #1) > How about letting void initialization be acceptable in @safe code only if > the value is initialized before being used? I'm not sure any of the rules for @safe functions require such checking. Not only that, but I'm not sure it's completely solvable. That could result in cases where it's clear from reading the code that the function initializes, but it's something the compiler can't tell. It's much more straightforward to disallow it. I think the cost of initialization is so low, that we aren't going to affect code that much. Disallowing =void for value types in safe code would be my second choice. --
