misplaced @trust?

[Walter Bright via Digitalmars-d]

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