Encapsulating trust

[Daniel Murphy via Digitalmars-d]

"Dmitry Olshansky"  wrote in message news:ltv91u$2mtc$1 at digitalmars.com...

> Quite recently a lot of work has been done to make most of Phobos usable 
> in @safe code.
>
> While a very welcome effort, it caused a number of doubts in particular 
> due to the boilerplate required to isolate a small amount of unsafe 
> operations and slap "@trusted" over it.
>
> See e.g. Denis argument:
> https://github.com/D-Programming-Language/phobos/pull/2465
>
> There were proposals for language changes along the lines of having 
> @trusted block alike to debug/version blocks, but nothing ever came out of 
> them.
>
> Without language support I decided it worth a shot to create a universal 
> wrappers to establish a consistent convention. A use of such wrapper 
> should indicate that a @system function call or language feature was 
> hand-verified.
>

>
> What do you guys think?

I think this is an abuse of @trusted.  It takes unsafe operations, and 
re-presents them as @safe options by renaming them.  Now, you can do use 
@system things in @safe functions without the compiler detecting it.

Take the `addrOf` function for example.  This is equivalent to adding a new 
version of the '&' operation, which does exactly the same thing except it's 
allowed in @safe code.  The `addrOf` function should _not_ be @trusted, 
because when used from @safe code it can cause escape the address of a local 
etc, just like '&' can.

Because these functions violate the meaning of @trusted, that @trusted 
functions must be @safe although the compiler can't prove them @safe, you've 
increased the surface of @trusted.  Now an audit of @trusted code must 
include all functions that call `addrOf` and friends.

I don't think this is a good idea.  Each time @trusted is used, it should be 
on a function that is completely @safe to call.  I think this is worth more 
than the cost in verbosity.

Lambdas and nested functions are special in that they can't be called from 
other code, so they only have to be @safe in the context of the enclosing 
function.  They do still need to make sure they don't violate @safe, 
otherwise the entire enclosing function will need to be manually checked.

eg
void fun(int a) @safe
{
...
    p = @trusted () { return &a; }
...
}

This function is now essentially @trusted, because although the unsafe '&' 
operation was inside the trusted block, the @safe function now has a pointer 
it should not have been able to get.