@system blocks and safer @trusted (ST) functions

[Bruce Carneal]

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:
>
> 1. Code that is automatically checked 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`.
>
> 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.

There is no getting away from manually checking the @system 
block(s) so (2) would be , IIUC, just as it is now wrt compiler 
assumptions.

The improvements on the status quo include the ability to easily 
delimit "should check *very* closely" code and the corresponding 
ability to engage @safety checking on any remainder.

>
>> 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.

Yes.

>
> 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`.
>

Yes.  As Walter has put this, we'd be forcing args/operands to 
"come in through the front door" rather than sneaking in the back.