[Issue 18016] using uninitialized value is considered @safe but has undefined behavior

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=18016

Steven Schveighoffer <schveiguy at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy at yahoo.com

--- Comment #2 from Steven Schveighoffer <schveiguy at yahoo.com> ---
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.

--