@system blocks and safer @trusted (ST) functions

[Steven Schveighoffer]

On Sunday, 25 July 2021 at 06:13:41 UTC, jfondren wrote:
> On Sunday, 25 July 2021 at 05:05:44 UTC, Bruce Carneal wrote:
>> The presence of one or more @system blocks would enable @safe 
>> checking elsewhere in the enclosing @trusted function.
>
> This has an unfortunate result: if in maintenance you edit a 
> @trusted function to remove its @system blocks, it'll quietly 
> no longer be checked as @safe.

Yes, but there is no point in a `@trusted` function without 
`@system` blocks. The compiler should warn about it so it gets 
changed (but should not ever be deprecated).

>
> Of the current behavior, Walter's said that he doesn't want 
> @trusted blocks because they should be discouraged in @safe 
> code. With this change, we'll have exactly what he doesn't want 
> with different names: s/@trusted/@system/, s/@safe/@trusted/, 
> and the exact same behavior: @system blocks are just what 
> @trusted blocks would've been, and @trusted code with @system 
> blocks in it is just @safe code with a different name.

The name is the important change. A `@safe` function shouldn't 
require manual verification. A `@trusted` function does. The 
`@safe` function with `@trusted` escape gives the impression that 
the `@safe` parts don't need checking, but they do. It's also 
difficult to use tools to check which parts need review when 
focusing on memory safety.

>
> Instead of people accepting that @safe "isn't really @safe" in 
> the presence of @trusted blocks, and that the whole body of the 
> function has to be audited, with this change we'll have 
> s/@safe/@trusted/ blocks that aren't really @safe in the 
> presence of @system blocks, and that the whole body of the 
> function has to be audited. The "you have to audit this" 
> signifier is the same, an internal lower-protection block, and 
> all that's gained is that the function attribute's spelled 
> differently. Is this really worth it?

Yes.

>
> One way to avoid the "unfortunate result" above is to permit 
> @trusted blocks in @safe code. Which results in Rust equivalent 
> functionality: @safe code is checked as @safe, @safe code with 
> internal @trusted blocks is still checked as @safe but people 
> know to audit it, and @system code isn't checked as @safe.

We already have that with `@trusted` lambdas today. This just 
changes the name to identify which parts are actually trusted and 
need review.

> I appreciate that there's a vision also to 
> @safe/@trusted/@system, but it doesn't seem to have stuck, with 
> Phobos having more than twice as many @trusted lambdas than 
> @trusted functions:
>
> ```
> phobos$ grep -rP '\W\(\) @trusted' --include '*.d'|wc -l
> 238
> phobos$ grep -rP '\w\(\) @trusted' --include '*.d'|wc -l
> 111
> ```

`@trusted` lambdas are required inside templates where you want 
code to be `@safe` when the type parameters allow it. The 
resulting function itself needs to be marked `@trusted` with the 
lambdas replaced with `@system` blocks to achieve the same 
effect, as memory safety review is still needed.

-Steve