@safe accessing of union members

[ag0aep6g]

On Thursday, 18 March 2021 at 18:24:21 UTC, Q. Schroll wrote:
> Maintaining the invariant of an aggregate type necessarily 
> includes auditing the whole module which has access to its 
> private data. Annotating member variables @system can help with 
> that reducing the audit to @trusted and @system functions in 
> the module. Unless @system becomes the default for member 
> variables, it cannot be relied upon for cases like ShortString.

You're saying (correct me if I'm misrepresenting you): I might 
forget putting @system on a safety-critical variable, and then I 
can still mess with it from @safe code. So I have to check all 
@safe code anyway, to see if it touches a safety-critical 
variable that wasn't marked.

I think that's missing an important aspect of @trusted: @trusted 
code is not allowed to rely on such variables for safety. The 
ShortString example in the DIP shows invalid code. It only 
becomes valid when DIP 1035 is implemented and `length` is marked 
@system.

Condensed into a piece of code:

     char[15] data;
     ubyte length_1;
     @system ubyte length_2;
     @trusted char[] f() { return data.ptr[0 .. length_1]; }
     @trusted char[] g() { return data.ptr[0 .. length_2]; }

`f` is always invalid. `g` is invalid without DIP 1035. It 
becomes valid with DIP 1035.

> The DIP points that out in Example: User-Defined Slice: 
> "Instead, every function that touches ptr and length, including 
> the @safe constructor, must be manually checked."

Allowing an @safe constructor to set a @system variable might be 
a mistake. This was pointed out in the DIP review. But auditing 
all @safe constructors is still less work than auditing all @safe 
code.