Simplification of @trusted

jmh530 john.michael.hall at gmail.com
Thu Jun 17 15:33:03 UTC 2021


On Thursday, 17 June 2021 at 14:30:58 UTC, Steven Schveighoffer 
wrote:
> [snip]
> The goal is to guarantee that *as long as* your @trusted 
> functions and blocks have a @safe interface, then @safe code 
> does not need to be checked. When I say "not require review" I 
> mean "I have checked all the @trusted code, and it has a sound 
> @safe interface, so all @safe code that may call it have no 
> need for review." We will never have a marking that is 
> language-guaranteed to not require review.
>

I think I've suggested before a @safe-strict, or something like 
that, that is the same as @safe but only allows calling 
@safe-strict functions (@safe/@trusted/@system functions can all 
call a @safe-strict function). The idea would be that those 
shouldn't need to be reviewed for the issues that @safe attempts 
to address.

You could then have @safe-strict blocks to complement the @system 
blocks you discussed previously (I've come along to the idea that 
@trusted blocks is a bad idea, you really just need these two). 
The idea would be that the @safe-strict blocks within a 
@safe/@trusted/@system function would be mechanically checked and 
since they do not call any @safe/@trusted/@system not need to be 
reviewed. Of course, one might argue that this results in mixing 
up @system code with @safe-strict code. However, it also helps 
separate out the safer parts of unsafe code. For instance, this 
approach means that you have a backwards compatible way to have 
the code in a trusted function that is not in a system block be 
checked manually (see below, @system block would be optional).

```d
@trusted void foo()
{
     @safe-strict {
         //mechanically checked code that can't call any 
@safe/@trusted/@system functions
     }
     //system code
}
```


More information about the Digitalmars-d mailing list