@trusted attribute should be replaced with @trusted blocks

[Timon Gehr]

On 16.01.20 03:06, Joseph Rushton Wakeling wrote:
> On Thursday, 16 January 2020 at 01:53:18 UTC, Timon Gehr wrote:
>> It's an implementation detail. If you care about the distinction, you 
>> should check out the function's implementation, not its signature.
> 
> Sure. But on a practical day-to-day basis, @safe vs @trusted signatures 
> help to prioritize one's allocation of care somewhat.
> ...

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.

@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. 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, so the difference in signature 
is meaningless unless you adhere to specific conventions (which the 
library you will be considering to use as a dependency most likely will 
not do).


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