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

Paul Backus snarwin at gmail.com
Thu Mar 4 21:22:37 UTC 2021


On Thursday, 4 March 2021 at 20:10:05 UTC, Steven Schveighoffer 
wrote:
> In the example for (2):
>
> struct Handle {
>     @system int handle;
> }
[...]
> If Handle(-1) is unsafe, what is stopping me from doing:
>
> @safe Handle sneakyHandle = Handle(-1);

Nothing, because Handle(-1) isn't unsafe. If your next question 
is "then why use a @system variable?", the answer is that this 
isn't intended to be a realistic example. It's just an 
illustration of the semantics of @system variables.

If you actually wanted to maintain an invariant like "Handles 
can't be negative", you would have to write a constructor:

struct Handle {
     @system int handle;
     this(int n) @safe {
         assert(n >= 0);
         handle = n;
     }
}

> Another note, the ShortString example is unsafe, even with the 
> DIP, as `s[]` will provide access to data that might move 
> elsewhere.

ShortString doesn't contain internal pointers, and the compiler 
won't let `s[]` outlive the ShortString's lexical scope, which 
means that the problem in issue 17448 [1] can't happen here. So 
it should be fine, unless there's something else I'm missing.

It does require DIP 1000, which means that opIndex should be 
annotated with `return`.

[1] https://issues.dlang.org/show_bug.cgi?id=17448


More information about the Digitalmars-d mailing list