@system blocks and safer @trusted (ST) functions

[claptrap]

On Wednesday, 28 July 2021 at 12:49:28 UTC, Paul Backus wrote:
> On Wednesday, 28 July 2021 at 08:40:47 UTC, claptrap wrote:

> If I understand correctly, there are two problems being 
> diagnosed in this discussion (overall--not just in your post), 
> and two solutions being proposed:
>
> * __Problem #1:__ most uses of function-level `@trusted` are 
> mistakes, and allow too much code to go without automatic 
> checks.
>
> * __Proposed Solution #1:__ get rid of function-level 
> `@trusted` as it currently exists. Instead, automatic safety 
> checks will only be disabled in specially-marked blocks (like 
> in Rust). This will encourage programmers to disable automatic 
> checking only for the specific lines of code where it is 
> actually necessary, rather than for the entire function.
>
> * __Problem #2:__ `@trusted` lambdas make code harder to review 
> and maintain because they have implicit dependencies on the 
> surrounding `@safe` code.
>
> * __Proposed Solution #2:__ ban `@trusted` lambdas, and force 
> programmers to put their `@trusted` code into separate 
> functions, which communicate with `@safe` code explicitly via 
> arguments and return values. (See: [Walter's PR][1]).
>
> There is logic to both of these proposals, but their solutions 
> conflict: one pushes for less use of function-level `@trusted`, 
> the other for more use of it.
>
> [1]: https://github.com/dlang/dlang.org/pull/3077

Agree 100%.

Maybe you can just ban trusted lambdas from having access to the 
surrounding scope?

Or ban unsafe blocks from having access to the surrounding scope, 
but then you need to have a way to pass stuff in, maybe like...

@system (int[] foo, float bar) { ... }

unsafe blocks could be lowered to a trusted lambda maybe?