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