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

Timon Gehr timon.gehr at gmx.ch
Wed Jun 17 16:47:33 UTC 2020


On 17.06.20 16:37, Andrei Alexandrescu wrote:
> On 6/17/20 10:30 AM, jmh530 wrote:
>> Regardless, it means that @safe is not currently safe.
> 
> Affirmative. Clearly this is the problem. Opting into @system by means 
> of an variable annotation that is NOT FLAGGED IF MISSING is not helping.
> 
> Making @system opt-in is completely backwards.

No, it is not.

It is a tool to write correct and efficient @trusted code. @trusted code 
has to ensure memory safety regardless of how @safe code behaves. The 
type system and @safe checks allow @trusted code to make assumptions 
about @safe code. Introducing specific features that restrict what @safe 
code can do is precisely the right way to go about it and it has been 
the way @trusted works from the start.

The goal of any modular analysis is to be able to at least assign blame 
to any problem that ends up cropping up anyway, this is true in 
particular for D's @safe/@system/@trusted and the blame always lies in 
@trusted functions. Without @system variables, @trusted functions always 
have to check that their invariants hold. This can range from expensive 
to completely intractable, in particular if the invariants are related 
to the state of memory allocators.

You are either misunderstanding @trusted or arguing in favor of 
completely redesigning D's safety system and thereby destroying what 
makes @trusted great. In that case we can just as well switch to the 
inferior Rust `unsafe` model with unclear assumptions and guarantees and 
get rid of @trusted entirely.


More information about the Digitalmars-d mailing list