On 07/28/12 15:47, Andrei Alexandrescu wrote: > On 7/28/12 7:05 AM, Artur Skawina wrote: >> On 07/28/12 02:08, David Nadlinger wrote: >>> @trusted in its current form needs to go. Its design is badly broken, as it >>> leaks implementation details and encourages writing unsafe code. >> >> The problem with @trusted is that it is transitive. >> >> @trusted should allow unsafe operations in the covered scope (right now - >> the function), but disallow calling unsafe (@system) code. > > No. Trusted means "hand-checked, good to go". It can do anything.
Exactly, but the only way for it to mean anything is if it really /can/ be hand-checked. A "trusted" function that calls arbitrary, potentially unsafe code cannot be trusted. You can't audit code that isn't available. 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. artur
