@trusted attribute should be replaced with @trusted blocks

[Steven Schveighoffer]

On 1/16/20 10:46 AM, Ola Fosheim Grøstad wrote:
> On Thursday, 16 January 2020 at 15:30:45 UTC, Steven Schveighoffer wrote:
>> The second is how much manual review is needed for the code. This is a 
>> signal to the reviewer/reader. In the current regime, the two reasons 
>> for marking are muddled -- we don't have a good way to say "this needs 
>> manual checking, but I also want the benefits of mechanical checking". 
>> This is why I proposed a change to trusted code STILL being 
>> mechanically checked, unless you want an escape. This would allow you 
>> to mark all code that needs manual review trusted, even if it's 
>> mechanically checked (it still needs review if the system-calling 
>> parts can muck with the data).
> 
> As was pointed out @trusted does not achieve much more than a comment, 
> so why not just have a statement- / operator-level escape using a 
> distinguishable and greppable marker like @@. Then you can just prepend 
> that to all function calls or operations that are unsafe:
> 
> safe_function(…){
>       ptr = …
>       //TRUSTED: this is safe because x, y, z
>       @@free(ptr);
> }
> 
> Then leave on any existing mechanical checks and keep adding @@ until it 
> passes.
> 

Enforcing the name of the comment helps the greppability. And putting 
@trusted on the entire function helps avoid grep finding blocks whereby 
you now have to dig back up to find the context.

@safe functions with no trusted escapes have a much different level of 
review required. If you can assume all the inputs are valid, then the 
function shouldn't need review -- even if it calls trusted functions.

I was looking for a distinction from @safe functions like this, and 
@safe ones with escapes.

I do like the @@ syntax, though @system free(ptr); isn't much worse.

-Steve