@trusted attribute should be replaced with @trusted blocks

[Joseph Rushton Wakeling]

On Thursday, 16 January 2020 at 15:45:46 UTC, Steven 
Schveighoffer wrote:
> In fact, because of how the system works, @safe code is LESS 
> likely to mean what you think.

I'm not quite sure I follow what you mean here, can you 
clarify/explain?

> If you see a @safe function, it just means "some of this is 
> mechanically checked". It doesn't mean that the function is so 
> much more solid than a @trusted function that you can skip the 
> review. It can have trusted escapes that force the whole 
> function into the realm of needing review.

Yes, agreed.  And hence why your proposal for how to improve 
@trusted really makes sense.

> If we moved to a scheme more like I was writing about in the 
> post you quoted, then they actually do start to take on a more 
> solid meaning. It's still not fool-proof -- @safe functions can 
> call @trusted functions, which can call @system functions. BUT 
> if everyone does the job they should be doing, then you 
> shouldn't be able to call @trusted functions and corrupt 
> memory, and you should not have to necessarily review @safe 
> functions.

Yes, this was exactly how I interpreted your proposal.

> There are still cases where you still have to review functions 
> that are @safe which do not have inner functions that are 
> trusted. These are cases where data that is usually accessible 
> to safe functions can cause memory problems in conjunction with 
> trusted functions. When you need to break the rules, it's very 
> hard to contain where the rule breaking stops.

For example, in a class or struct implementation where a private 
variable can be accessed by both @safe and @trusted methods ... ?