@trusted considered harmful

[Lars T. Kyllingstad]

On Saturday, 28 July 2012 at 00:08:30 UTC, 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
> ———————————
>
> [...]
>
> A Solution
> ——————————
>
> Let me make something clear first: I am _not_ intending to 
> remove @trusted from the language. As a bridge between the 
> @safe and @system worlds, it is an integral part of SafeD. What 
> I'm proposing is:
>
>  1) Remove the distinction between @safe and @trusted at the 
> interface (ABI, API) level. This implies changing the name 
> mangling of @trusted to Nf, and consequently removing the 
> distinction in DMD altogether (at least in user-facing parts 
> like .stringof and error messages). In theory, this is a 
> breaking change, but as any code that doesn't treat them the 
> same is buggy anyway, it shouldn't be in practice. As for 
> std.traits.FunctionAttribute, we could either make trusted an 
> alias for safe, or just remove documentation for the former and 
> keep it around for some time (there is no way to deprecate an 
> enum member).
>
>  2) The first step is necessary, but mainly of cosmetic nature 
> (think `pure`, `pure2`). We still need to address for the 
> granularity and attribute inference problem. The obvious 
> solution is to add a "@trusted" declaration/block, which would 
> allow unsafe code in a certain region. Putting @trusted in the 
> function header would still be allowed for backwards 
> compatibility (but discouraged), and would have the same effect 
> as marking the function @safe and wrapping its whole body in a 
> @trusted block. It could e.g. look something like this (the @ 
> prefix definitely looks weird, but I didn't want to introduce a 
> new keyword):
>
> ---
>  void foo(T)(T t) {
>    t.doSomething();
>    @trusted {
>      // Do something dirty.
>    }
>    t.doSomethingElse();
>    @trusted phobosFunctionWhichHasNotBeenMarkedSafeYet();
>  }
> ---
>
> This is similar to other constructs we have today, for example 
> debug {}, which allows impure code. It can be debated whether a 
> block »argument« should introduce a new scope or not (like 
> static if). The latter currently seems much more attractive to 
> me, but I suppose it could be confusing for some.
>
> In any case, while there is probably quite a bit of 
> bikeshedding to be done for 2), I don't think there is much 
> controversy about 1). So, let's try to get this done shortly 
> after the 2.060 release – as discussed above, it is very 
> unlikely that the change will break something, but the odds 
> still increase over time. Also, there is currently a Phobos 
> pull request [4] which will be influenced by the outcome of 
> this discussion.


I completely agree with the above. @trusted should be applied to 
as small blocks of code as possible -- preferably to individual 
statements -- to make it easier for the programmer to verify and 
maintain the safety of the code.

Lars