@trust is an encapsulation method, not an escape

[via Digitalmars-d]

On Friday, 6 February 2015 at 13:28:59 UTC, Steven Schveighoffer 
wrote:
> The bottom line of my reasoning is that code changes over time, 
> by different people. Context is forgotten. It's much better to 
> have the compiler verify you know what you are doing when 
> working with @trusted than it is to just allow anyone to inject 
> code anywhere.

Actually, I think this argument goes against what you are arguing 
for. Anything within a @trusted section has a big warning sign 
attached to it that says "cannot modify this without detailed 
review". But the compiler cannot verify that a @safe function 
with local @trusted blocks are actually safe, so it only buys you 
a false sense of security.

It is also much easier to bring a large @trusted block to safety 
than a small one, e.g. to have one big @trusted chunk that does:

1. obtain resource
2. process resource
3. copy resource
4. free resource
5. return copy

The problem is the process around @trusted given that there will 
be no sound verification system in D.

Maybe it should have been called "@manually_proven_safe" instead, 
to discourage use...