• simendsjo (18/18) Jul 26 2015 Is there a reason why you would hide the fact that a function is
• anonymous (7/25) Jul 26 2015 As far as I know, it doesn't matter. Both @safe and @trusted
• Adam D. Ruppe (15/19) Jul 26 2015 The Phobos idiom you've seen there is to have little trusted
• Joseph Rushton Wakeling via Digitalmars-d-learn (7/11) Jul 26 2015 If I recall right, the argument wasn't over the principle of trying to i...
• Dicebot (3/3) Jul 26 2015 I remember doing something like that in druntime because of
• Johannes Pfau (5/9) Jul 26 2015 That's probably related to the fact that safe and trusted functions
• Steven Schveighoffer (16/18) Jul 27 2015 But you can, at least now you can, maybe it's changed.

"simendsjo" <simendsjo gmail.com> writes:

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();
     }

"anonymous" <anonymous example.com> writes:

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.

"Adam D. Ruppe" <destructionator gmail.com> writes:

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.

Joseph Rushton Wakeling via Digitalmars-d-learn writes:

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 ;-)

"Dicebot" <public dicebot.lv> writes:

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

Johannes Pfau <nospam example.com> writes:

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.

Steven Schveighoffer <schveiguy yahoo.com> writes:

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