@system blocks and safer @trusted (ST) functions

[Steven Schveighoffer]

On Sunday, 25 July 2021 at 12:05:10 UTC, Steven Schveighoffer 
wrote:
> On Sunday, 25 July 2021 at 06:13:41 UTC, jfondren wrote:
>> 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.

One thing that is incredibly important to get right here is the 
way to specify what to do with templates. I've been thinking 
about this a bit, and even this isn't the right way to do things 
(specify the function as `@trusted` and mark the actual trusted 
part as `@system`), because you want the compiler to infer 
`@system` for certain instantiations, and `@trusted` for others.

What we need is a way to say "this function should be `@trusted` 
iff certain sections of code are inferred `@safe`".

Perhaps the correct mechanism here is to encapsulate the 
`@trusted` parts into separate functions, and make sure the API 
is `@safe` (e.g. static inner functions).

I think it would be too confusing to allow `@system` blocks 
inside inferred templates.

-Steve