a design flaw in DIP1035, its remedy, and the implication for @system variables

[Paul Backus]

On Wednesday, 13 April 2022 at 12:14:53 UTC, Zach Tollen wrote:
> ```d
> void fn() @safe {
>     () @trusted { x = new int; }();  // we're @safe now, right?
>     *x = 10; // error: @system variable x may not be accessed 
> in @safe code
> }
> ```
> Promoting `x` to a `@system` variable has had the effect of 
> basically making it unusable. Eventually, the user realizes 
> that the only way solve the problem is to declare the original 
> variable `@trusted`.
> ```d
> @trusted extern int* x;
> ```

Worth noting that this is not the *only* solution. One can also 
provide a `@trusted` interface using getter and setter functions; 
e.g.,

```d
extern int* x; // inferred @system
@system bool initializedX = false;

@trusted void safeX(int* value)
{
     x = value;
     initializedX = true;
}

@trusted int* safeX()
in (initializedX)
{
     return x;
}

@safe void fn()
{
     safeX = new int;
     *safeX = 10;
}
```