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

[Andrei Alexandrescu]

On 6/17/20 11:58 AM, Dennis wrote:
> Forgetting a @system annotation does not allow you to break @safe with 
> DIP 1035. Let's take this example:
> ```
> int* x = cast(int*) 0x0F48;
> void main() @safe {
>      *x = 3;
> }
> ```
> This compiles today. With DIP 1035, x would be _inferred_ @system. 
> Marking it @safe would be an error, marking it @system would be 
> redundant.

Cool. So the unsafe part is embedded in the history of x, and its 
@system attribute carries that to @safe code using the variable. That's 
akin to https://en.wikipedia.org/wiki/Taint_checking, perhaps the DIP 
could mention that.

(Note that this is also disallowing a number of correct programs:

int* x = cast(int*) 0x0F48;
void main() @safe {
     x = new int;
     *x = 3;
})

Leading with this example would do good for the paper. Looking through 
the current narrative, it's difficult to distinguish fixable trouble 
with @safe from the value added by the proposed feature.

Going through the code samples:

* Good illustratory example of status quo: void main() @safe { int* a = 
void; ... }

* Sumtype example: move to existing issues that need a fix for 
__traits(getMember). Replace with a compelling example such as the one 
above.

* The example with @safe vs. @safe: is not very relevant because fixing 
it invalidates it.

* Probably getPtr() is a good opener that could go as far back as the 
rationale. Fundamentally: variables don't carry information about their 
being initialized in safe code. This is very much akin to tainted.

* The bool story seems like a problem with bool more than anything. It 
seems excessive to mark something as common and useful as bool as a 
@system type. The right solution is to fix bool.

Generally confining the issues with @safe that need solving anyway to 
their own section (or an appendix) and presenting a value proposition 
independently of that would make the proposal stronger.