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

[Dukc]

On Thursday, 25 February 2021 at 09:23:35 UTC, Mike Parker wrote:
> This is the feedback thread for the second round of Community 
> Review of DIP 1035, "@system Variables".

The rationale and description sections disagree on behaviour of 
`extern` global variables of unsafe type. Rationale says the 
compiler should disallow it in @safe code "since it's initial 
value is unknown", yet an example in description says:
```
extern int* x0;                   // @safe by default
```

I see problems in this rule: "An exception to the above rules 
<about variable @safe inference> is made on unsafe types when the 
compiler knows the resulting value is safe". With global or 
static variables, no problem. But when initializing a local 
variable, this may result in implementation-defined behaviour. It 
could be changed to something like: "Iff the initialization 
expression is required to be executed at compile by the spec, and 
the expression evaluates as a value the compiler knows to be 
safe, the variable is inferred as @safe".

Which leads to, what are the values compiler considers to be 
safe? I think I know roughly: every `.init` value, arrays and 
pointers pointing only to safe values, and structs/classes where 
all fields either:

1: are safe with safe type
2: are safe with unsafe type but safe value
3: are same as the fields static initialization value.

But this probably needs elaboration. It's self-explanatory with 
pointers and arrays, but not with user-defined unsafe types. It 
might be easier to just discard the exception about @safe 
inference: @safe initializers return @safe values, @system 
initializers return @system values, period.

All in all, I like this DIP.