@trust is an encapsulation method, not an escape

[ponce via Digitalmars-d]

On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright wrote:
> The solution is to regard @trusted as a means of encapsulating 
> unsafe operations, not escaping them. Encapsulating them means 
> that the interface from the @trusted code is such that it is 
> usable from safe code without having to manually review the 
> safe code for memory safety. For example (also from std.array):
>
>   static void trustedMemcopy(T[] dest, T[] src) @trusted
>   {
>     assert(src.length == dest.length);
>     memcpy(dest.ptr, src.ptr, src.length * T.sizeof);
>   }
>
> I don't have to review callers of trustedMemory() because it 
> encapsulates an unsafe operation (memcpy) with a safe interface.

If I understand correctly, your rule o be a trusted function is:
"Unable to create a memory corrutpion whatever the arguments".

But here:
- dest or src could be the null slice
- the assert would go away in release

So I though this example _could_ corrupt memory?



>
> The reason @trusted applies only to functions, and not to 
> blocks of code, is that functions are the construct in D that 
> provides an interface. Arbitrary blocks of code do not have a 
> structured interface. Adding @trusted { code } support will 
> encourage incorrect uses like the opening example. The 
> existence of @trusted blocks will require review of every line 
> of code in the function that encloses it, and transitively 
> every function that calls it!
>
> Adding @trusted as a function attribute, on the other hand, 
> only requires review of the function's interface to determine 
> if it is acceptable to use in safe code. Safety review of its 
> callers is unnecessary.