@trust is an encapsulation method, not an escape

[Tobias Pankrath via Digitalmars-d]

On Friday, 6 February 2015 at 08:58:05 UTC, Walter Bright wrote:
> On 2/6/2015 12:31 AM, Kagamin wrote:
>> On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright 
>> wrote:
>>>  static void trustedMemcopy(T[] dest, T[] src) @trusted
>>>  {
>>>    assert(src.length == dest.length);
>>>    memcpy(dest.ptr, src.ptr, src.length * T.sizeof);
>>>  }
>>
>> Should be enforce: assert doesn't guard against malicious 
>> usage.
>
> Cue my endless attempts to explain the difference between input 
> errors and logic errors :-(

I agree with you, that this should be an assert, but then it 
cannot be @trusted. A @trusted function should provide it's 
guarantee for all input that can be crafted in @safe code. This 
is why this


void bar()
{
     ubyte[] a;
     a.ptr = 0; // arbitrary value as long as NOT from an allocator
     a.len = 1;

     setToZero(a);
}

is not a valid counter-example and that memcpy cannot be 
@trusted. It has no safe interface.


Back to topic. Since @trusted must provide a safe interface, I 
don't think it makes much sense to attach @trusted to smaller 
code blocks than functions. That might not be true for the 
opposite: @safe blocks where the compiler turns the safety check 
back on.

This prevents that a @trusted/@safe function becoming @system 
breaks the @trusted guarantee of called functions.

void bar(void* argument) @trusted { ... }

void forward() @trusted
{
     // REVIEW: forwards arguments to bar, which is @trusted, so 
we can
     // trust forward as well
     void* p = malloc(...);
     bar(arguments);
     free(p);
}

Changing bar to @system is a breaking change and currently a 
silent one. This is a maintenance problem I see as well. Solution:

void forward() @trusted
{
     void* p = malloc(...);
     // safe is bar is safe, so turn compiler checks on again.
     @safe  { bar(p); }
     free(p);
}


Introducing an error in an @trusted function is _not_ an 
maintenance horror. While your @safe-ty guarantee is out of the 
window, it can be catched my reviewing one function: the one 
where the error is introduced in. Making a @trusted function 
@system forces us to review all @trusted functions calling the 
now @system function.