@trusted considered harmful

[Andrei Alexandrescu]

On 7/27/12 8:08 PM, David Nadlinger wrote:
> First, there is no point in having @trusted in the function signature.
> Why? From the perspective of the caller of the function in question,
> @safe and @trusted mean exactly the same thing. If you are not convinced
> about that, just consider that you can wrap any @trusted function into a
> @safe function to make it @safe, and vice versa.

If @trusted is not part of the signature, we can't enable e.g. analyzers 
that verify an entire program or package to be safe. This is not 
something that's currently used, but I'd hate to look back and say, 
"heck, I hate that we conflated @trusted with @safe!"

> One issue is that the distinction unnecessarily restricts the
> implementation in terms of interface stability. Yes, @safe and @trusted
> are equivalent from the caller's perspective, but they are mangled
> differently. This means that changing a function signature from one to
> the other is a breaking change to the ABI, and as the mangled name is
> available in the program (which is e.g. what
> std.traits.FunctionAttributes), also to the API.

I salute this quest for stability, but I don't find it the argument all 
that compelling. If one makes changes to a library, well, some changes 
will require clients to relink. Some don't. I don't see why we'd make a 
thing of the particular change @safe <-> @trusted. Is this often, 
fundamental, big,...?

> Thus, you can't just change @trusted to @safe or vice versa on the
> implementation side if you make changes code which require @trusted,
> resp. cause it to be no longer needed.

Can't parse this sentence following "if you make changes code..."

> But the much bigger problem is that @trusted doesn't play well with
> template attribute inference and makes it much too easy to accidentally
> mark a function as safe to call if it really isn't. Both things are a
> consequence of the fact that it can be applied at the function level
> only; there is no way to apply it selectively to only a part of the
> function.

This could be a more serious problem. Could you please write a brief 
example that shows attribute deduction messing things up? I don't 
understand how marking a template as @trusted is bad.

> The obvious solution is to add a "@trusted"
> declaration/block, which would allow unsafe code in a certain region.

This is sensible, but I fail to figure how it adds value over marking 
functions as @trusted. Sure, it's finer-grained, but it's also less 
structured.


Andrei