Discussion Thread: DIP 1035-- at system Variables--Community Review Round 2

[Steven Schveighoffer]

On 3/2/21 5:15 PM, Guillaume Piolat wrote:
> On Thursday, 25 February 2021 at 09:21:20 UTC, Mike Parker wrote:
>>
>> The review period will end at 11:59 PM ET on March 11, or when I make 
>> a post declaring it complete. Discussion in this thread may continue 
>> beyond that point.
>>
>> Here in the discussion thread, you are free to discuss anything and 
>> everything related to the DIP. Express your support or opposition, 
>> debate alternatives, argue the merits, etc.
>>
> 
> So, in a few words, the merit of the DIP is that after this change, you 
> have to review only @trusted functions to ensure a @safe function hasn't 
> broken an invariant of the aggregate.

I would change this to "you can make it possible" to only have to review 
@trusted functions. Without actually marking the variables @system, you 
would still have to review @safe code.

> Which is strange to me since I was under the impression @safe/@trusted 
> was only about memory safety. But in a way it makes sense to use it for 
> "general bugs" since @trusted function will be audited. So, no real 
> opinion here. Why not.

Inside a @trusted function, you can assume that any data entering the 
function is only set to values that obey the @safe rules. Currently, 
that means certain invariants cannot be realized (like that a length 
field identifies how many bytes are valid past a pointer field).

This DIP allows you to restrict the rules further so more assumptions 
can be made in the @trusted function. You can assume that @system 
variables never were modified directly by @safe functions, and 
therefore, it's only necessary to review @trusted and @system functions 
to ensure the invariants hold.

Given the theory that most code is @safe and should be marked or 
inferred that way, you can therefore vastly reduce the amount of code 
that needs review for memory safety.

-Steve