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

[Dennis]

On Wednesday, 10 June 2020 at 12:36:13 UTC, Stanislav Blinov 
wrote:
> The last one (`this.z = z`) is not an assignment, it is 
> initialization, and should be allowed; that is, unless you want 
> to change the constructor spec for this case.

Yes. I tried out some examples with immutable to figure what dmd 
counts as initialization and what as assignment, but I think I 
made a mistake there.

> Further down:
>
>> struct Wrapper(T) {
>>     @system T t;
>>     this(T t) @trusted {
>>         this.t = t; // Oops! Calls a `@system` copy constructor
>>     }
>> }
>
> ...is a bad example for two reasons. First, appropriate 
> implementation of Wrapper won't be calling a copy constructor 
> here, it will move. Second, T may have a @system destructor 
> which would be called when constructor returns.

Maybe the name Wrapper is misleading since it gives some semantic 
expectations. I'm considering simply calling it 'S'.
The fact that a @system constructor gets implicitly trusted as 
well only supports the example, which is trying to show the 
problems with @trusted constructors.

> As before, that last line is not memory corruption, it's UB.

Each example has two consecutive moments:
A) Memory gets in a state that violates the programmer's intended 
invariants.
B) Because of that, immutable memory is mutated, or memory 
outside a pointer's allocated block is accessed.

If I understand correctly, you claim that A) should be called 
memory corruption and B) is undefined behavior, while I call B) 
memory corruption. In the D specification, corrupting memory is 
undefined behavior, and undefined behavior can manifest in memory 
corruption, so when talking about @safe the terms are sometimes 
used interchangeably. Also, as far as the D language is 
concerned, there's nothing wrong with e.g. setting the pointer to 
Cstring to something not null terminated, only the resulting out 
of bounds memory accesses are.