@trusted attribute should be replaced with @trusted blocks

[ag0aep6g]

On 15.01.20 22:08, Johannes Pfau wrote:
> Am Wed, 15 Jan 2020 20:14:13 +0100 schrieb ag0aep6g:
> 
>> On 15.01.20 19:41, Joseph Rushton Wakeling wrote:
[...]
>>> So, put that together with what I wrote above, and you have something
>>> that allows better validation of the internals of @trusted functions,
>>> and still gives the user clarity about which functions are safe in
>>> their own terms, and which are safe based on some programmer provided
>>> guarantees.
>>
>> You're saying that an @safe function `f` is somehow more guaranteed to
>> be safe than an @trusted function `g`, even though `f` may be calling
>> `g`. I don't see how that makes sense.
[...]
> A trusted function in D is supposed to have a safe interface: For each
> possible combination of argument values, a trusted function must not
> cause invalid memory accesses. This is the only reason you can safely
> call trusted functions from safe functions. It's the programmers
> responsibility to design trusted function APIs in a way so they can't be
> misused.

I completely agree, but I'm not sure how it's related to my rejection of 
Joseph's statement that @trusted "gives the user [= caller] clarity 
about which functions [...] are safe based on some programmer provided 
guarantees".

The distinction between @safe and @trusted matters when looking at the 
implementation of a function. It doesn't matter when calling an 
@safe/@trusted function, precisely because @trusted function must have 
safe interfaces just like @safe functions.