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.
