@trust is an encapsulation method, not an escape

[Brad Roberts via Digitalmars-d]

I figured that someone would have already objected to part of this, but 
the definition is stronger than I believe is intended for D:

On 2/5/2015 5:23 PM, H. S. Teoh via Digitalmars-d wrote:
>
> 2) I think we also all basically agree that the *intent* of @trusted is
> to be an encapsulation mechanism, or to present a safe API, or however
> you want to describe it. I.e., if a function is marked @safe, then it
> must be impossible to cause it to do something unsafe by passing it the
> wrong arguments. Whatever it does under the hood should not have any
> observable unsafe effect on the outside world. I'm pretty sure everyone
> also agrees with this; I don't think anyone is advocating that we should
> changee this intent. So can we please also take this as a given, and
> stop repeating it at each other as if we don't all already know it?

Specifically, the 'impossible to cause it to do something unsafe by 
passing it the wrong arguments' part.

For example, this is valid @safe code:

@safe void setToZero(ubyte[] foo)
{
     foo[] = 0;
}

How about now:

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

     setToZero(a);
}

@safe code is memory safe when passed good inputs.  @safe code does not 
have to detect or prevent garbage input from causing harm.   The 
promises of @trusted aren't stronger than that either.