@trust is an encapsulation method, not an escape

[David Nadlinger via Digitalmars-d]

On Friday, 6 February 2015 at 16:50:51 UTC, Tobias Pankrath wrote:
> On Friday, 6 February 2015 at 16:40:10 UTC, David Nadlinger 
> wrote:
>>
>> This still does not solve the template inference problem 
>> though, unless you make it a "non- at trusted" block instead of 
>> requiring @safe-ty.
>
> Don't understand. If that matters, the code shouldn't be marked 
> @trusted
> in the first place.

Let's say you have a template function that accepts a range. For 
performance, you want to do some of the processing in a way that 
is @system, but can be verified to be correct for all inputs in 
this specific case. In other words, that piece of code can be 
rightfully @trusted. However, marking the whole function as 
@trusted would be a mistake, as the primitives of the range that 
is your input data might be @system.

Using @trusted blocks (which is what is currently emulated by the 
nested functions/lambdas), you can just mark your unsafe code as 
@trusted and let the compiler figure out the safety of the whole 
function. @safe blocks wouldn't work for this, as you'd 
inadvertently require the user-supplied input range to have 
@safe/@trusted primitives.

>> And then you'd end up with the—at least to my eyes—rather 
>> absurd situation that a template function that is marked 
>> @trusted might actually end up being @system.
>>
>> David
>
> How?

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

   // …
}
---

This seems incredibly backwards. Not only is it confusing to 
read, it also encourages bugs where operations mistakenly end up 
being @trusted by forgetting to mark, say, an added call to 
r.empty as untrusted. On the other hand, it is much more unlikely 
that you accidentally add a new @trusted block. It seems obvious 
that explicitly whitelisting a small number of potentially 
dangerous but safe operations is much less error-prone approach 
than disabling compiler checks for everything and then having to 
remember to blacklist all unverified external dependencies.

David