Is there a reason why you would hide the fact that a function is trusted rather than safe? Technically it doesn't matter, right? To me, it seems like this would give wrong assumptions to the caller.

The reason I ask is because I found the following in std.concurrency:

    @property Tid thisTid() @safe
    {
        // TODO: remove when concurrency is safe
        auto trus = delegate() @trusted
        {
            if( thisInfo.ident != Tid.init )
                return thisInfo.ident;
            thisInfo.ident = Tid( new MessageBox );
            return thisInfo.ident;
        };

        return trus();
    }

On Sunday, 26 July 2015 at 11:38:31 UTC, simendsjo wrote:
> Is there a reason why you would hide the fact that a function is trusted rather than safe? Technically it doesn't matter, right? To me, it seems like this would give wrong assumptions to the caller.
>
> The reason I ask is because I found the following in std.concurrency:
>
>     @property Tid thisTid() @safe
>     {
>         // TODO: remove when concurrency is safe
>         auto trus = delegate() @trusted
>         {
>             if( thisInfo.ident != Tid.init )
>                 return thisInfo.ident;
>             thisInfo.ident = Tid( new MessageBox );
>             return thisInfo.ident;
>         };
>
>         return trus();
>     }

As far as I know, it doesn't matter. Both @safe and @trusted functions must be memory safe. So I don't see a point in doing that delegate dance.

But it doesn't make a difference to the caller either. They can't assume any more or less about an @safe function than about an @trusted one.

On Sunday, 26 July 2015 at 11:38:31 UTC, simendsjo wrote:
> Is there a reason why you would hide the fact that a function is trusted rather than safe? Technically it doesn't matter, right? To me, it seems like this would give wrong assumptions to the caller.

The Phobos idiom you've seen there is to have little trusted blocks inside an otherwise safe function. (That specific example seems unnecessary since there's no other code around it, but often the @trusted part is just a small bit of the whole function.)

The idea is to get the @safe checks for everywhere you can, then use the @trusted delegate to escape from that for just a couple lines so you manually check that part while having more confidence in the rest of the function.

If the whole function is marked @trusted, the compiler doesn't try to check it at all - it just takes your word for it.

There was a bit of argument about this a while ago in bugzilla, not everyone agrees it is a good idea. I don't remember where though.

On 26/07/15 14:24, Adam D. Ruppe via Digitalmars-d-learn wrote:
> If the whole function is marked @trusted, the compiler doesn't try to check it
> at all - it just takes your word for it.
>
> There was a bit of argument about this a while ago in bugzilla, not everyone
> agrees it is a good idea. I don't remember where though.

If I recall right, the argument wasn't over the principle of trying to isolate the @trusted bits, but that @trusted was being used only to wrap up the particular function call that was technically triggering @system stuff, rather than the entirety of what actually needed to be trusted.

I can't remember a good example off the top of my head, but no doubt the stuff is there in the bugzilla reports ;-)

I remember doing something like that in druntime because of objects - you can't override @safe method prototype with @trusted one.

Am Sun, 26 Jul 2015 13:11:51 +0000
schrieb "Dicebot" <public@dicebot.lv>:

> I remember doing something like that in druntime because of objects - you can't override @safe method prototype with @trusted one.
> 

That's probably related to the fact that safe and trusted functions have different mangled names. This also means that going from trusted to safe later on causes ABI breakage.

On 7/26/15 9:11 AM, Dicebot wrote:
> I remember doing something like that in druntime because of objects -
> you can't override @safe method prototype with @trusted one.
>

But you can, at least now you can, maybe it's changed.

In answer to the original question, the given code is quite unnecessary. However, the @trusted moniker would appear in the docs instead of @safe. Perhaps that's the reason.

BTW, the reason to put @trusted islands is because you have fully encapsulated @trusted parts inside a function. If the implementation details of the islands leak out to the @safe code, you should have the entire function be trusted (@safe can only really be useful if the building blocks its using are also @safe or manually verified to be @safe). This is often difficult to prove, and code inside phobos/druntime was written at various stages of the "@trusted" philosophy. So you are bound to find inconsistencies.

IMO, that function simply should be marked trusted until it can be marked safe.

-Steve