[Issue 12941] Everything should be @unsafe by default, and explicitly vetted (and documented) as @safe

[via Digitalmars-d-bugs]

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

--- Comment #11 from Jonathan M Davis <issues.dlang at jmdavisProg.com> ---
(In reply to Sobirari Muhomori from comment #10)
> (In reply to hsteoh from comment #3)
> > All declarations without initializers are @safe, regardless of the type of
> > the declared symbol(s).
> 
> What if the default initializer violates the type's invariant?

That doesn't make anything unsafe. It just means that calling anything on the
type will violate the invariant, and an AssertError will be thrown when built
with assertions enabled. @safe is safety with regards to memory safety and
really has nothing to do with invariants aside from whether an invariant is
marked with @safe, @trusted, or @system. And having an invariant doesn't save
you from @safety problems with default-initializers which are @system (e.g.
initializing to void), because the invariant isn't run in release mode. And
even if the invariant were guaranteed to be run, the only way that it could
guarantee @safety with a void initializer would be if it checked the value that
that member was initialized to, and the compiler verified that that was being
done, which it doesn't do. As far as the compiler is concerned, the invariant
is pretty much just a normal function that happens to have assertions in it.
It's only special because it gets run before and after calls to public
functions and gets compiled out in release. The compiler doesn't generally care
about what's actually inside the invariant.

--