@trust is an encapsulation method, not an escape

[David Nadlinger via Digitalmars-d]

On Friday, 6 February 2015 at 17:50:05 UTC, Tobias Pankrath wrote:
>> I was referring to a hypothetical "untrusted" block that might 
>> be used something like this:
>>
>> ---
>> void foo(Range)(Range r) @trusted {
>>  // ...
>>
>>  untrusted {
>>    r.front;
>>  }
>>
>>  // Your manually checked code.
>>
>>  untrusted {
>>    r.popFront;
>>  }
>>
>>  // …
>> }
>> ---
>
> Using current semantics we must not mark foo @trusted, if 
> r.front and
> r.popFront aren't. Using the proposed @safe-blocks (are those 
> untrusted blocks the same?) we could guarantee that, by 
> wrapping the use of r.front and r.popFront in @safe-blocks.
>
> This is limiting because now we cannot provide an foo marked 
> @system for all @system ranges without boiler plate or 
> duplicating the function.
>
> Correct?

Yes.

The "untrusted" blocks were an ad-hoc invention to show how @safe 
blocks could be modified to actually work in this case (for 
template functions, don't require @safe, but mark the function 
@system if the contents are unsafe), but that this modification 
results in a much less desirable design than just straight up 
having @trusted blocks.

David