On 07/28/12 18:16, Andrei Alexandrescu wrote: > On 7/28/12 10:34 AM, Artur Skawina wrote: >> So the result is bugs (like the ones mentioned in this thread), where @safe >> is bypassed, because the @trusted functions aren't expecting to be used >> with "unsafe" ones. @trusted bypasses *all* safety checks, not just those >> in the hand-checked code. This is something that you will want sometimes, >> but in most cases is neither necessary nor desirable. When dealing with >> safety one has to be conservative. The proposals to limit the scope of >> @trusted only address the symptoms, not the cause. If the design is fixed, >> many of the reasons for introducing the finer-grained @trusted disappear, >> and it is the truly unsafe (@trusted that calls @system) code that needs >> the extra annotations -- which is a good thing. Papering over design bugs >> never is. > > I don't understand what you suggest here. Is it a sort of a refinement of > @trusted?
Maybe my other response to David makes things more clear. Yes, there would be a cost to this change (some lib and user code would need additional annotations), but I think it'd be worth it, as right now it is much too easy to 'break' the @safe guarantees, often w/o even realizing it. artur
