@system blocks and safer @trusted (ST) functions

[Bruce Carneal]

On Thursday, 29 July 2021 at 13:20:41 UTC, claptrap wrote:
> 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.

A design tension that Joseph and I are working with is that 
between local readability and practical safety.  One of the ideas 
being batted around is to allow parameterless read-only access to 
the preceding scope from within scoped @ncbc (not checked by 
compiler) blocks.  There are other ideas in this area.

The DIP ideas are still, quite clearly, in the half-baked 
category.  We (Joseph and I) are considering beerconf updates 
where we can solicit input on 3/4 baked ideas and open the door 
to new possibilities in a more productive setting.  That said, if 
lightning strikes and you can't wait til beerconf please feel 
free to drop me an email.

Finally, I've not tightly coordinated with Joseph on this 
response, so he may have additional/better information to impart.