@trust is an encapsulation method, not an escape

[Walter Bright via Digitalmars-d]

On 2/6/2015 3:02 PM, Zach the Mystic wrote:
> No, at least three of us, Steven, H.S. Teoh and myself have confirmed that we've
> moved beyond requesting @trusted blocks. We are no longer requesting them. We
> are requesting *@system* blocks, which can only appear in @trusted and @system
> functions. Any unsafe code appearing in a @trusted function which is not inside
> a @system block is an error. We've changed the name, but I think it will make a
> world of difference regarding how you will look at it. Marking '@system' code
> inside a @trusted function is exactly what is requested. Your message about
> '@trusted' being only acceptable as an interface has been heard. There will be
> no @trusted blocks, only @system blocks, which are the exact same thing, except
> they can only appear in @trusted and @system functions.
>
> This solution appeals to me greatly. It pinpoints precisely where unsafe code
> can generate; it catches unintended safety violations in all @trusted code
> outside @system blocks, as requested by many people so far; it makes systems
> programming highly visible, with redundancy at the function signature and at the
> unsafe code itself. I really think it's spot on!

I suspect that such a feature would simply lull people into a false sense of 
security in that merely tagging an unsafe cast with @system and the compiler 
accepting it is good enough.

My evidence for this is how @trusted was used in Phobos.