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

[Stanislav Blinov]

On Wednesday, 10 June 2020 at 08:39:48 UTC, Mike Parker wrote:

In proposed-changes:

> struct T {
>     @system int y;
>     @system int z = 3; // allowed
>     this(int y, int z) @safe {
>         this.y = y; // allowed, this is initialization
>         this.y = y; // second time disallowed, this is 
> assignment to a `@system` variable
>         this.z = z; // disallowed, this is assignment
>     }
> }

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.

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.

---

> bool becomes an unsafe type

Nice one.

---

In Examples:

> void main() @safe {
>     Var v = 1.0;
>     v.type = Var.Type.Str; // not allowed after this DIP
>     writeln(v.getString()); // memory corruption: the union 
> messed up the string
> }

The last line is not memory corruption, it's undefined behavior.

> void main() @safe {
>     auto stack = getStack!string();
>     stack._top += 1; // not allowed after this DIP
>     writeln(stack.pop); // memory corruption: garbage string is 
> printed
> }

Ditto.

---

A custom allocator.

> void main() @safe {
>     string[] strArr = customAlloc!string(3);
>     heapIndex = 0; // mess up allocator integrity! not allowed 
> after this DIP.
>     int[] intArr = customAlloc!int(3);
>     intArr[] = -1; // overwrites string array
>     writeln(strArr[0]); // memory corruption: constructed 
> pointer
> }

The `intArr[] = -1;` is memory corruption. Last line, as before, 
is just UB.

---

A custom slice type

...is self-contradicting. "...one does not want 4 or 8 bytes to 
store the length when 2 suffices... ...SmallSlice!T is no larger 
than a regular T[]---it still fits in two CPU registers."

> struct SmallSlice(T) if (__traits(isPOD, T)) {
>     @system private T* ptr = null;
>     @system private ushort _length = 0;
>     ubyte[size_t.sizeof-2] extraSpace; // 2 on 32-bit, 6 on 
> 64-bit

How, then, is it "small", if SmallSlice!T.sizeof == (T[]).sizeof 
? That you only use two out of (4 or 8) bytes doesn't make it 
"small" :)

---

A zero-terminated string

> void main() @safe {
>     Cstring c = cStringLiteral!"hello";
>     c.ptr = new char('D'); // not allowed after this DIP
>     writeln(c.length); // memory corruption: strlen likely goes 
> past the single 'D' character
> }

As before, that last line is not memory corruption, it's UB. 
Corruption happens on the "not allowed after this DIP" line.