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

[Dennis]

On Wednesday, 10 June 2020 at 13:56:11 UTC, Timon Gehr wrote:
> However, I don't think the examples should be using `assert` to 
> validate input data. At the very least, those asserts should be 
> in `in` contracts, but even then, I am not sure if the 
> semantics of `assert` supports your use case. In particular, 
> does `-release` mean "disable memory safety checks" like 
> `-noboundscheck` does?

Personally I often find myself writing `if (!x) {assert(0);}` 
instead of `assert(x);` for exactly that reason: I want to assert 
something that's necessary for @safe.
I'm not sure if that's the idiomatic way to do it though. I'll 
change the examples to use that unless you have a better 
suggestion.

> Memory safety cannot depend on the correctness of a `@safe` 
> constructor.

> Consider the following slightly adapted example from the DIP:

You could say that the problem is that `execute` is wrongly 
`@trusted` since it assumed something about `opcode` that is not 
enforced by VmInstruction. I get what you're saying though, and 
it comes back to "@trusted assumptions about @safe code", which 
unfortunately did not come to concensus.

https://forum.dlang.org/thread/rahiuh$2t8h$1@digitalmars.com?page=1

I'll come back to this later in the discussion thread, but the 
short version is:
Ideally all important trusted parts of the program have a 
@trusted annotation nearby, but I'm afraid it is infeasible. I 
was unable to find a satisfying design, though I'm open to 
suggestions.

> Minor:
> - "Ownsership and borrowing in D"
> - "static initializtion"

Thanks.