@trusted attribute should be replaced with @trusted blocks

[Joseph Rushton Wakeling]

On Thursday, 16 January 2020 at 00:40:12 UTC, ag0aep6g wrote:
> And that isn't useful to a user in any way.

The fact that I personally find it useful -- and going by this 
discussion thread, so do some others -- means that this claim 
can't possibly be true.

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

@safe on a function tells you no more than it promises: that the 
compiler will alert you to any memory safety violations it is 
able to detect in that function's implementation.  If it does not 
detect any, that could be because none are present, or it could 
be that at some point nested inside the code it calls there is 
something @trusted that the compiler does not attempt to validate.

@trusted on a function, on the other hand, explicitly tells you 
that its safety is contingent on something other than compiler 
validation, and that you should not expect the compiler to 
validate _any_ part of its internals.

Do you seriously not see any difference between an annotation 
that tells you: "this function should be memory-safe, and the 
compiler will attempt to validate this to the best of its 
ability" versus, "this function should be memory-safe, but the 
compiler will not make any attempt to validate that"?  And do you 
seriously not see any value in having that distinction clear?

Obviously the allegedly @safe function _could_ just be a thin 
wrapper around a @trusted lambda containing all sorts of horrible 
crack.  But on balance of probabilities, in any library written 
by vaguely competent people, that should probably not be your 
_first_ assumption.

> (It is useless, though.)

Don't mistake "I don't find it useful" for "No one finds it 
useful".

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

FWIW I do think it may be a bit of a code smell or anti-pattern 
to have nested @trusted functions inside @safe functions.  Of 
course, there's still the possibility that a @safe function can 
call some external but private @trusted function, but it reduces 
the attack space if the internal code of a @safe function can be 
fully validated _in its own terms_ (i.e. if it can be validated 
that there is nothing _inside the function_ that could cause a 
memory safety bug).

BTW, that's part of the motivation for my suggestions at the 
beginning of this thread about how @trusted could be improved:
https://forum.dlang.org/post/heujvxcsppiyagxfvliv@forum.dlang.org

If the compiler would validate all the contents of @trusted 
functions except for lines contained in `@system { ... }` blocks 
(see the original example if it's not clear what I mean), then 
that would probably be a preferred way to achieve what developers 
currently do using @safe functions with some nested @trusted 
lambdas.  And that would probably mean that APIs would be 
annotated in a more informative way about the _true_ risk of 
memory safety bugs.