Can we just have struct inheritence already?

[Tim]

On Tuesday, 11 June 2019 at 00:30:27 UTC, Walter Bright wrote:
> If you want @safe to mean "no undefined behavior", that is a 
> valid opinion, but that is not what @safe in D is currently 
> defined as. It is currently defined as "memory safe". If you 
> can find a case where an int with garbage in it can cause 
> memory corruption in @safe code, that would indeed be a bug in 
> D.

The following code causes memory corruption, because a bool has 
garbage in it.

import std.stdio;

// Returns newly allocated data with increased value if b is true.
// Returns same data otherwise.
const(int)* test(immutable int *data, bool b) @trusted
{
     int *data2;
     if(!b)
     {
         writeln("b seems to be false");
         // The cast can be trusted, because data2 will only be 
modified if b is true.
         data2 = cast(int*)data;
     }
     else
     {
         writeln("b seems to be true");
         data2 = new int(*data);
     }

     if(b)
     {
         writeln("b seems to be true");
         *data2 += 1;
     }
     return data2;
}

void main() @safe
{
     bool b = void;
     immutable int *data = new immutable int(1);
     writeln("data before: ", *data);
     const int *data2 = test(data, b);
     writeln("data after: ", *data);
     writeln("data2 after: ", *data2);
}

After compiling it with dmd and running it I get the following 
output:
data before: 1
b seems to be false
b seems to be true
data after: 2
data2 after: 2

The immutable integer pointed to by data is modified. The 
function test is @trusted, but only modifies the immutable data, 
because b seems to be true and false at the same time.
Normally a bool is internally 0 or 1 and the compiler can assume 
that. If b has another value and !b is implemented as ~b, then b 
and !b can both be true.

This means, that uninitialized data can result in memory 
corruption.