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...
