Blog Post: What Does Memory Safety Really Mean in D?

[Paul Backus]

On Wednesday, 26 August 2020 at 15:34:26 UTC, Dennis wrote:
> On Wednesday, 26 August 2020 at 14:29:46 UTC, Dukc wrote:
>> I think there is a workaround to the variable access being 
>> always safe. Something like this in a dedicated module:
>>
>> ```
>> struct SystemVar(T, bool safeVal)
>> {  private T _var;
>>    static if (safeVal) @safe pure nothrow @nogc auto val()
>>    {  return _var;
>>    }
>>    else pure nothrow @nogc auto val(){return _var;}
>>    pure nothrow @nogc ref var(){return _var;}
>> }
>> ```
>
> This currently does not protect against:
> - SystemVar.tupleof[0] (unless you have -preview=dip1000 set)
> - __traits(getMember, SystemVar, "_var")
> - aliasing (put SystemVar!int in a union with a plain int / 
> cast SystemVar!int[] from int[])
> - void initialization

Of course, you could also argue that these are things that 
shouldn't be allowed in @safe code to begin with--regardless of 
whether pointers are involved.

I think presenting @system variables as "protection" against 
memory corruption is the wrong way frame the discussion. The 
problem is that, currently, it is only possible to provide @safe 
access to certain kinds of data (discriminated unions, 
ref-counted pointers, etc.) by having @trusted code make 
assumptions about @safe code that must be manually verified.

There is, technically, nothing wrong with this. The D language 
spec does not place any restrictions on what assumptions you are 
allowed to make in @trusted code; it merely requires that you do 
the legwork to manually verify those assumptions if you want the 
compiler's automatic verification of @safe code to give the 
correct result.

What @system variables do is allow you to document, in 
machine-readable form, a particular kind of assumption ("this 
variable is never accessed directly from @safe code"), and have 
the compiler check it for you. In other words, they make @trusted 
code more *expressive* and *ergonomic*.