@trusted attribute should be replaced with @trusted blocks

[Joseph Rushton Wakeling]

On Thursday, 16 January 2020 at 03:34:26 UTC, Timon Gehr wrote:
> You have to be careful when writing a @trusted function, not 
> when calling it. If you do not trust a given library, there is 
> no reason to be more careful around a @trusted API than around 
> a @safe API, as they do not mean different things.

Thanks for being patient enough to clarify the issues here.  This 
helps to make much clearer the thinking behind the point of view 
that's been articulated elsewhere in this discussion, that the 
@trusted/@safe distinction is there for library maintainers 
rather than users.

I agree that it's _primarily_ there for maintainers, but I don't 
agree that it has _no_ value for users (more on that below).  But 
your observations do make clear how unreasonable my rather 
judgemental "I'm coming to the conclusion ..." remarks were, so 
apologies to everyone for that.

(It's no excuse, but I was quite tired when I wrote that, and so 
probably not exercising as much good judgement as I ought.)

> @safe does not fully eliminate risk of memory corruption in 
> practice, but that does not mean there is anything non-absolute 
> about the specifications of the attributes.

Would we be able to agree that the absolute part of the spec of 
both amounts to, "The emergence of a memory safety problem inside 
this function points to a bug either in the function itself or in 
the initialization of the data that is passed to it" ... ?

(In the latter case I'm thinking that e.g. one can have a 
perfectly, provably correct @safe function taking a slice as 
input, and its behaviour can still get messed up because the user 
initializes a slice in some crazy unsafe way and passes that in.)

> As I am sure you understand, if you see a @safe function 
> signature, you don't know that its implementation is not a 
> single @trusted function call

Yes, on this we agree.  (I even mentioned this case in one of my 
posts above.)

> so the difference in signature is meaningless unless you adhere 
> to specific conventions

Here's where I think we start having a disagreement.  I think it 
is meaningful to be able to distinguish between "The compiler 
will attempt to validate the memory safety of this function to 
the extent possible given the @trusted assumptions injected by 
the developer" (which _might_ be the entirety of the function), 
versus "The safety of this function will definitely not be 
validated in any way by the compiler".

Obviously that's _more_ helpful to the library authors than 
users, but it's still informative to the user: it's saying that 
while the _worst case_ assumptions are the same (100% 
unvalidated), the best case are not.

> (which the library you will be considering to use as a 
> dependency most likely will not do).

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

The distinction only becomes meaningless if one is unable to 
deep-dive and explore the library code.

>> I'm coming to the conclusion that much of the differences of 
>> opinion in this thread are between folks who want to see 
>> things as absolutes, and folks who recognize that these 
>> features are tools for mitigating risk, not eliminating it.
>> 
>
> I was not able to figure out a response to this sentence that 
> is both polite and honest.

Well FWIW, don't feel the need to be polite to me if you don't 
think I deserve it :-)  But in any case, apologies again to 
everyone for those remarks.  They were unfair and based on a 
misinterpretation of the positions being articulated.