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
