Encapsulating trust

[Dmitry Olshansky via Digitalmars-d]

01-Sep-2014 20:36, Daniel Murphy пишет:
> "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.
>

Only these that import stdx.trusted. Trivial to check.

> 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.

I'd be damned but it's made precisely because taking address is 
frequently needed in a function that is otherwise @safe. Alternative of 
marking the whole thing as @trusted ain't going in the right direction.

Instead of writing the same ugly shit (pardon local functions and 
lambda+call) everywhere, let just compose a set of markers (2-3 
functions) that indicate something as trusted block.

Obviously one can easily abuse it, much like @trusted can be easily 
abuse today, especially with templates where it's easy to fail in trap 
of putting @trusted on the whole function and trust pretty much any 3rd 
party type to be safe.

>
> 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.

They have in common is lot of noise that distracts and obfuscates the 
thing that already needs our full attention making it both bigger and 
harder to follow.

> 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.

Careful there - a trusted lambda must ensure that pointer is fine, 
although the means of getting it are @system. The same review-driven 
thing about @trusted remains.

-- 
Dmitry Olshansky