@trusted attribute should be replaced with @trusted blocks

[Joseph Rushton Wakeling]

On Wednesday, 15 January 2020 at 23:46:11 UTC, ag0aep6g wrote:
> You're saying that it is useful for me as a user of Phobos when 
> I see that, for example, std.stdio.File.open is @trusted [1], 
> right?

Yes, I am saying exactly that.

> I disagree. It doesn't mean anything other than @safe in that 
> context. Knowing that the function is @trusted instead of @safe 
> is of zero use to a user of Phobos. It cannot help them make 
> any decision whatsoever.

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.

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.

Contrast this with, say, Rust, where any function can do 
something like this:

     fn foo(x: &[int]) {
         unsafe {
             // any old horrible stuff can happen here
         }
     }

... where any number of memory safety bugs could exist in that 
`unsafe { ... }` block, and yet there is no possible clue from 
the API that this could be going on.

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.e., it's a tool for library authors, not for library users. 
> You clearly spoke of an "external" or "outside" user of the 
> function before.

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).  
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?"