@trusted considered harmful

[Dmitry Olshansky]

On 28-Jul-12 04:08, David Nadlinger wrote:
> 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).
>

No question here, @trusted should be usable in place of @safe 
_transparently_.

>   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.
>

Finally proper granularity for trusted!
I'd say that SafeD is still unusable mostly because @trusted is too 
blunt (your example from std.uuid).
The day writeln works for all safe types (with safe/trusted toString or 
whatever) I'd call SafeD barely usable.

I believe it need not introduce another scope.



-- 
Dmitry Olshansky