Encapsulating trust

[Walter Bright via Digitalmars-d]

On 8/31/2014 6:47 AM, Dmitry Olshansky wrote:
> import core.stdc.string;
> import trusted;
>
> void main() @safe
> {
>
>      char[] msg = "Hello!".dup;
>      char[] msg2 = msg;
>      import trusted; // may also use static import for absolute clarity
>      assert(call!memcmp(addrOf(msg[0]), addrOf(msg2[0]), msg.length) == 0);
> }

I don't agree with the notion of having primitives that provide escapes from 
@safe - it means the interleaving of @safe and @system code becomes too easy, 
and too easy to miss.

I also don't agree with the notion of having @trusted blocks of the form:

     @trusted {
         ... system code ...
     }

We already have a mechanism to do that - @trusted nested functions. The code 
example becomes:

   void main() @safe {
      char[] msg = "Hello!".dup;
      char[] msg2 = msg;

      void checkEquals(const char[] msg, const char[] msg2) pure @trusted {
        assert(msg.length == msg2.length);
        assert(memcmp(msg.ptr, msg2.ptr, msg.length) == 0);
      }

      checkEquals(msg, msg2);
   }

Granted, this can be abused to subvert the @safe/@trusted/@system system, but 
that has always been the case. Note that I added an assert to make checkEquals() 
actually trustworthy. The QA code reviewer can still grep for @trusted and flag 
them for special review.

These sorts of nested functions should inline and pose no extra overhead.