misplaced @trust?

[H. S. Teoh via Digitalmars-d]

On Thu, Feb 05, 2015 at 03:39:16PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
[...]
> I think the *fundamental* problem with @trusted (currently) is that it
> assumes all the code it covers was written simultaneously and is not
> allowed to morph. This isn't the way code is written, it's massaged
> and tweaked over long periods of time by different people.

Thank you, that's exactly what I've been trying to say, but rather
poorly. This is what makes the current incarnation of @trusted
unworkable in real-life. Putting it on a function is a stamp of approval
that the code has been verified by a human. Unfortunately, the element
of time has been neglected. It may have been verified back when it was
first committed, but now that 10 other people have stuck their grubby
hands into the code, who knows if the original verification still
applies? Yet the @trusted label continues to be a stamp of approval
claiming that the function is still safe. It's like a car insurance
sticker without expiry date. The insurance company may have gone bust
for all I know, but it sure looks good that my car is still "insured"!

There needs to be some kind of "change insurance" to @trusted. If
somebody makes a careless code change that may break the promise of
@trusted, there needs to be a way for the compiler to detect this and
complain loudly. Of course, we can't prevent *malicious* changes, since
there's always another way to work around the compiler, but in the
reasonable cases at the very least, careless mistakes ought to be caught
and pointed out. Such as a @safe helper function used by a @trusted
function becoming @system because somebody modified the original
implementation. Requiring some kind of annotation on exactly what parts
of a @trusted function rely on unsafe (or rather, safe but unverifiable
by the compiler) operations helps by introducing a barrier for mistakes:
the compiler will reject your code unless you consciously mark it up as
trusted (thereby indicating that you have manually verified the code --
or maliciously introducing unsafe code in @trusted, as the case may be).


T

-- 
Computers shouldn't beep through the keyhole.