@system blocks and safer @trusted (ST) functions

[claptrap]

On Thursday, 29 July 2021 at 08:16:08 UTC, Joseph Rushton 
Wakeling wrote:
> On Wednesday, 28 July 2021 at 17:25:18 UTC, claptrap wrote:
>> Do you have ideas on how to stop unsafe blocks accessing the 
>> variables from the surrounding scope? Is that even a goal for 
>> the DIP?
>
> I'm not sure it necessarily is.  Consider the following example 
> (using the proposed @trusted-with- at system-blocks syntax):
>
>
> ```D
> /// Writes something into the provided buffer, e.g. filling the
> /// buffer with random bytes
> extern(C) void writeIntoCBuffer (int* ptr, size_t len) @system;
>
>
> void writeIntoDBuffer (ref int[] buf) @trusted
> {
>     @system { writeIntoCBuffer(buf.ptr, buf.length); }
> }
> ```
>
> That seems like a reasonable use-case for a @trusted wrapper of 
> an underlying @system function, but if the @system block was 
> forbidden from accessing variables from the surrounding scope, 
> it wouldn't be possible.
>
> Does that make sense, or have I misunderstood what you had in 
> mind?

Not exactly, obviously if they cant access variables from the 
surround scope they'd be useless. But i think the idea (not 
something i knew about until this thread) is to have a safe api 
between trusted and system. So there's controlled / restricted 
access. Otherwise if you have a system block inside a trusted 
function, the system code could just trash anything it wants from 
the enclosing scope, which makes any guarantees you have from the 
code being checked a bit pointless.

So it's not just about narrowing down the amount of code that is 
marked @system, but also the amount of state that it can access.

IIUC that was the original reason for limiting 
@safe/@trusted/@system to only apply on functions. So it forces 
you think about API between them. But I guess it didn't work out 
as expected.