@trust is an encapsulation method, not an escape

[Steven Schveighoffer via Digitalmars-d]

On 2/6/15 8:42 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang at gmail.com>" wrote:
> On Friday, 6 February 2015 at 13:28:59 UTC, Steven Schveighoffer wrote:
>> The bottom line of my reasoning is that code changes over time, by
>> different people. Context is forgotten. It's much better to have the
>> compiler verify you know what you are doing when working with @trusted
>> than it is to just allow anyone to inject code anywhere.
>
> Actually, I think this argument goes against what you are arguing for.
> Anything within a @trusted section has a big warning sign attached to it
> that says "cannot modify this without detailed review". But the compiler
> cannot verify that a @safe function with local @trusted blocks are
> actually safe, so it only buys you a false sense of security.

That is kind of the point behind H.S. Teoh's idea that @trusted code 
should be default @safe with @system escapes instead of today where it's 
default @system. If nothing else, it has discouraged the use of @trusted 
to mark code for extra scrutiny.

I'm coming to agree with him. Having a function marked @safe doesn't 
tell you whether there are @trusted blocks, and any @trusted blocks 
(despite the idea of having the compiler tell you when data was 
generated/touched by @trusted code) can bring into suspect the whole 
function. So marking a function @safe, and having it mean "this function 
has NO TRUSTED OR SYSTEM CODE in it whatsoever, is probably the right 
move, regardless of any other changes.

In fact, I would propose that it should be an error for @safe functions 
to have any non-static functions inside them (i.e. any place where the 
aliasing of @safe data is implicit). This is a departure from my 
previous position, but I think it still fits if we allow @trusted to 
mean what H.S. Teoh's proposal means.

> It is also much easier to bring a large @trusted block to safety than a
> small one, e.g. to have one big @trusted chunk that does:
>
> 1. obtain resource
> 2. process resource
> 3. copy resource
> 4. free resource
> 5. return copy
>
> The problem is the process around @trusted given that there will be no
> sound verification system in D.

What we really want is:

1. A way to say "this function needs extra scrutiny"
2. Mechanical verification as MUCH AS POSSIBLE, and especially for 
changes to said function.

Yes, we can do 2 manually if necessary. But having a compiler that never 
misses on pointing out certain bad things is so much better than not 
having it.

> Maybe it should have been called "@manually_proven_safe" instead, to
> discourage use...

@assume_safe would probably be the right moniker since that's what we 
use elsewhere. But it's water under the bridge now...

-Steve