On 2/6/15 8:42 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
<ola.fosheim.grostad+dl...@gmail.com>" wrote:
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.
That is kind of the point behind H.S. Teoh's idea that @trusted code
should be default @safe with @system escapes instead of today where it's
default @system. If nothing else, it has discouraged the use of @trusted
to mark code for extra scrutiny.
I'm coming to agree with him. Having a function marked @safe doesn't
tell you whether there are @trusted blocks, and any @trusted blocks
(despite the idea of having the compiler tell you when data was
generated/touched by @trusted code) can bring into suspect the whole
function. So marking a function @safe, and having it mean "this function
has NO TRUSTED OR SYSTEM CODE in it whatsoever, is probably the right
move, regardless of any other changes.
In fact, I would propose that it should be an error for @safe functions
to have any non-static functions inside them (i.e. any place where the
aliasing of @safe data is implicit). This is a departure from my
previous position, but I think it still fits if we allow @trusted to
mean what H.S. Teoh's proposal means.
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.
What we really want is:
1. A way to say "this function needs extra scrutiny"
2. Mechanical verification as MUCH AS POSSIBLE, and especially for
changes to said function.
Yes, we can do 2 manually if necessary. But having a compiler that never
misses on pointing out certain bad things is so much better than not
having it.
Maybe it should have been called "@manually_proven_safe" instead, to
discourage use...
@assume_safe would probably be the right moniker since that's what we
use elsewhere. But it's water under the bridge now...
-Steve
