@trusted attribute should be replaced with @trusted blocks

[ag0aep6g]

On Thursday, 16 January 2020 at 00:21:21 UTC, Joseph Rushton 
Wakeling wrote:
> I see what you're getting at here -- you mean that if we're 
> treating this function as a black box that I have no influence 
> over, then both @safe and @trusted mean the same thing in terms 
> of how that black box ought to behave.

Exactly.

> But that doesn't mean the distinction isn't useful.  It gives 
> me a clear indication that the code of this function (note, 
> _the code of this function_, not the code of other functions it 
> might call) could contain bugs that would allow memory safety 
> violations.

And that isn't useful to a user in any way.

[...]
> The fact that in a similar situation D forces you to annotate 
> the function with `@trusted`, and alert users to the 
> _possibility_ that memory safety bugs could exist within the 
> code of this function, is useful information even if you can't 
> access the source code.

I don't agree. @trusted doesn't alert you any more of the 
possibility of a memory safety bug than @safe. You can't assume 
that an @safe function won't corrupt your memory any more than 
you can assume the same about an @trusted function.

[...]
> It's clearly much less useful to anyone who doesn't have access 
> to the source code (which doesn't mean it's not useful at all).

(It is useless, though.)

>  But in general, given the ability to read and search the 
> source code (which users as well as authors can do), it's very 
> useful to be able to ask the question: "Of the code in this 
> project that claims to be memory safe, which bits could 
> actually contain memory safety bugs?"

Yes, but you find those interesting bits by grepping over the 
source code, not by looking at the attributes of public 
functions. Many @safe functions have @trusted innards that don't 
show up in API documentation.