@trusted attribute should be replaced with @trusted blocks

[Steven Schveighoffer]

On 1/16/20 6:50 AM, Joseph Rushton Wakeling wrote:

> Obviously in general one should not assume virtue on the part of library 
> developers.  But OTOH in a day-to-day practical working scenario, where 
> one has to prioritize how often one wants to deep-dive into 
> implementation details -- versus just taking a function's signature and 
> docs at face value and only enquiring more deeply if something breaks -- 
> it's always useful to have a small hint about the best vs. worst case 
> scenarios.
> 
> It's not that @safe provides a stronger guarantee than @trusted, it's 
> that @trusted makes clear that you are definitely in worst-case 
> territory.  It's not a magic bullet, it's just another data point that 
> helps inform the question of whether one might want to deep-dive up 
> front or not (a decision which might be influenced by plenty of other 
> factors besides memory safety concerns).
> 

In fact, because of how the system works, @safe code is LESS likely to 
mean what you think.

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.

I would say that today, @safe and @trusted are indistinguishable from 
each other as a user of the function.

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

-Steve