@system blocks and safer @trusted (ST) functions

[Paul Backus]

On Wednesday, 28 July 2021 at 08:40:47 UTC, claptrap wrote:
> If you're saying the proposed "system blocks inside trusted 
> functions" provide no advantage over teh current "trusted 
> lambdas inside safe functions" yes thats true. But I think the 
> point is trusted functions get more checking. Even if you say 
> well you can achieve the same by just using a trusted lambda 
> inside a safe function its not the same once you consider what 
> people actually do.
>
> If you have just one trusted function in your app, then 
> switching to this new regime would automatically give you more 
> checking.
>
> You have to take into account how people will actually behave, 
> even if you can technically achieve the same thing with the 
> current system.

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