@trusted considered harmful

[Jesse Phillips]

On Saturday, 28 July 2012 at 02:33:54 UTC, Jonathan M Davis wrote:
> On Saturday, July 28, 2012 04:05:14 Jesse Phillips wrote:
>> You aren't supposed to do dirty things in @trusted code. You're
>> supposed to  safely wrap a system function to be usable by a 
>> safe
>> function. The system function is supposed to be short and 
>> getting
>> its hands dirty. Remember this is about memory safety and not
>> lack of bugs safety.
>
> It's perfectly acceptable to put "dirty code" in an @trusted
> function. The difference between @trusted and @system is that 
> with @trusted,
> the programmer is guaranteeing that it's actually @safe 
> regardless of what
> arguments it's given, whereas @system is not only doing unsafe 
> things, but
> whether they're ultimately @safe or not depends on arguments 
> and/or other
> code, so the programmer _can't_ guarantee that it's @safe.

I realize you can, David Piepgrass was able to read into an idea 
which I didn't want to specifically state as it isn't as 
concerning. But why not limit @trusted to only do @safe and call 
@trusted. But I could see that as an extra layer of annoying, but 
it would keep the unsafe arithmetic and parameter passing in the 
@system functions. But again, not much thought on it and probably 
just be a layer of annoying.

For your example of the proposal, when does the compiler mark 
save() as @system over @trusted?

@property auto save()
{
    import std.conv;
    alias typeof((*_range).save) S;
    static assert(isForwardRange!S, S.stringof ~ " is not a 
forward range.");

    @trusted
    {
        auto mem = new void[S.sizeof];`
        emplace!S(mem, cast(S)(*_range).save);`
        return RefRange!S(cast(S*)mem.ptr);
    }
}

You make a call to _range.save in the @trusted block. So why 
isn't the function marked @trusted?

Having taken some more thought on the guarantee provided by @safe 
even when calling @trusted code, I do see the issue of templates 
always being trusted. As it could then be the logic in of the 
@safe which is doing something unsafe. This could be true with 
@trusted but at least the author had the opportunity to make it 
safe.

But at this point I'm not seeing how this proposal is helping. 
You do want save() to be @system when the underlining save() is 
@system, and @trusted otherwise? So I'm not seeing that here.