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

--- Comment #10 from Sobirari Muhomori <dfj1esp02@sneakemail.com> ---
(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?

--

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

--- Comment #11 from Jonathan M Davis <issues.dlang@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.

--

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

bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc

--- Comment #12 from bearophile_hugs@eml.cc ---
See also Issue 13838

--

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

--- Comment #13 from Sobirari Muhomori <dfj1esp02@sneakemail.com> ---
(In reply to Jonathan M Davis from comment #11)
> 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.

The method's safety can rely on invariant. If assertions are disabled the method will proceed and corrupt memory?

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|---                         |INVALID

--- Comment #14 from Walter Bright <bugzilla@digitalmars.com> ---
I don't think this is the place for a general open-ended discussion like this. Bugzilla issues should have specific action items that can be resolved. Seems like this should be reopened as a DIP if people care to pursue it.

For lack of anything better, I'll mark it as invalid.

--