On 2/5/2015 1:15 PM, Steven Schveighoffer wrote:
So you're saying that @safe is mechanically verified as long as @trusted
functions are manually reviewed.
Yes.
It's that manually reviewed part that I think
we have an issue with. And there is definitely a feel of "I can use trusted
because I know I will only call it this way" without considering future possible
calls.
It's no different from:
Q: the compiler gave me a mismatched type error!
A: put in a cast and it'll compile!
I.e. you can always find a way to make buggy, badly designed code compile. It's
up to whoever does the reviews to have some sort of standards.
An aspect of a well-designed encapsulation is the number of @trusted
interfaces is minimized. If you find an abstraction that has @trusted
sprinkled liberally through it, it's an indicator of a failed abstraction.
I think you just made this up :)
No, I've always thought of trusted that way. It isn't different from classes
that allow too many functions to access private members.
But I agree that @trusted should be used sparingly not liberally. The problem is
that when faced with such a huge function that calls one non-@safe one, marking
the whole thing as @trusted disables all the mechanical verification for
everything.
Then that's a candidate for a redesign of the abstraction.
