@system blocks and safer @trusted (ST) functions

[Steven Schveighoffer]

On Sunday, 25 July 2021 at 13:19:55 UTC, Paul Backus wrote:
> On Sunday, 25 July 2021 at 05:05:44 UTC, Bruce Carneal wrote:
>> At beerconf I committed to putting forward a DIP regarding a 
>> new syntactic element to be made available within @trusted 
>> functions, the @system block.  The presence of one or more 
>> @system blocks would enable @safe checking elsewhere in the 
>> enclosing @trusted function.
>
> Both before and after this proposal, there are 3 kinds of code:

4 kinds.

>
> 1. Code that is automatically checked for memory safety.

Split this into:

1. Code that is automatically checked for memory safety.
1a. Code that has portions that have mechanical checks, but 
overall still needs manual checking for memory safety.

> 2. Code that is assumed by the compiler to be safe, and must be 
> manually checked for memory safety.
> 3. Code that is not checked for memory safety, and is assumed 
> to be unsafe.
>
> Currently, (1) is marked `@safe`, (2) is marked `@trusted`, and 
> (3) is marked `@system`.

(1) and (1a) are marked `@safe`. The latter have `@trusted` 
lambdas but require manual verification. The difference between 1 
and 1a is pretty subtle.

>
> Under this proposal, (1) would be marked either `@safe` or 
> `@trusted`, (2) would be marked either `@trusted` or `@system`, 
> and (3) would be marked `@system`. I do not think this is an 
> improvement relative to the status quo.

Under this proposal (though I haven't seen exactly the proposal, 
but I think I've conversed with Bruce enough to have a good 
understanding), 1 becomes `@safe` *exclusively* (which is the 
main benefit), 1a becomes `@trusted`, 2 becomes legacy (marked 
`@trusted` but with no `@system` escapes) and IMO should be 
warned about to the user, 3 is still `@system`.

>
>> The problematic @trusted lambda escapes creeping in to "@safe" 
>> code could be replaced going forward by a more honestly named 
>> form, @trusted code with @system blocks. Best practices could 
>> evolve to the point that @safe actually meant @safe again.
>
> What makes `@trusted` lambdas problematic is that they 
> implicitly depend on everything in their enclosing scope, which 
> makes it easy for a change in the `@safe` portion of the code 
> to accidentally violate an assumption that the `@trusted` 
> portion depends on.
>
> If we want to address this issue at the language level, the 
> most direct solution is to require that `@trusted` lambdas make 
> their dependencies explicit. This can be done by requiring all 
> `@trusted` nested functions (of which lambdas are a special 
> case) to be `static`.

This doesn't solve the problem exactly. A `@trusted` lambda is a 
localized piece of code, and is prone to be abused with the 
justification "well, it's just for this one time, and I know what 
this function does". The compiler cannot enforce that the code 
inside (current) `@trusted` functions actually obeys the `@safe` 
API.

> Of course, this is a breaking change, so it would require a 
> deprecation process.

No, it shouldn't be. The idea is that `@trusted` code without 
`@system` escapes is still accepted as legacy code that works as 
before. I would recommend a message from the compiler though.

`@trusted` lambdas should be required to be static, though that 
still doesn't solve the abuse problem. Perhaps they should just 
be disallowed?

-Steve