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