misplaced @trust?

[Steven Schveighoffer via Digitalmars-d]

On 2/5/15 3:54 PM, Walter Bright wrote:
> On 2/5/2015 12:25 PM, Steven Schveighoffer wrote:
>> On 2/5/15 3:13 PM, Walter Bright wrote:
>>> So the question is, what does @trusted actually buy you, since the
>>> compiler can't check it?
>>>
>>> It serves as notice that "This function merits special attention during
>>> code review to check that it has a safe interface and that its
>>> implementation is correct."
>>>
>>
>> That also applies to @safe functions since they can call @trusted
>> functions.
>
> No - the @trusted function is reviewed to ensure it has a safe
> interface. Then there is no need to review for safety anyone that calls
> it. It's the whole point.

So you're saying that @safe is mechanically verified as long as @trusted 
functions are manually reviewed. 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.

I fully expect we can devise rules to make sure @trusted memory details 
do not leak out of the functions in an unsafe way (and have a much 
better, @safer code base). But it would be nice if the compiler helped 
enforce them.

>> In essense, @trusted buys you headaches. I think we should try to
>> lessen them.
>
> 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 :)

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.

There has to be a better way.

-Steve