Can we just have struct inheritence already?

[Exil]

On Friday, 14 June 2019 at 12:47:12 UTC, Timon Gehr wrote:
> On 14.06.19 07:43, Exil wrote:
>> On Friday, 14 June 2019 at 01:22:35 UTC, Timon Gehr wrote:
>>> On 14.06.19 03:17, Exil wrote:
>>>> On Friday, 14 June 2019 at 01:12:21 UTC, Timon Gehr wrote:
>>>>> On 14.06.19 02:23, Exil wrote:
>>>>>> On Thursday, 13 June 2019 at 21:26:37 UTC, Tim wrote:
>>>>>>> On Thursday, 13 June 2019 at 20:55:34 UTC, Exil wrote:
>>>>>>>> This problem happens because you are used @trusted. If 
>>>>>>>> you used @safe you wouldn't be able to increment 
>>>>>>>> pointers and modify the values the way you did in 
>>>>>>>> @trusted.
>>>>>>>
>>>>>>> Here is a completly @safe version:
>>>>>>>
>>>>>>> import std.stdio;
>>>>>>>
>>>>>>> static int[2] data;
>>>>>>> static int[253] data2;
>>>>>>>
>>>>>>> void test(bool b) @safe
>>>>>>> {
>>>>>>>     data[b]++;
>>>>>>> }
>>>>>>>
>>>>>>> void main() @safe
>>>>>>> {
>>>>>>>     bool b = void;
>>>>>>>     writeln(data, data2);
>>>>>>>     test(b);
>>>>>>>     writeln(data, data2);
>>>>>>> }
>>>>>>>
>>>>>>> If b is valid only data can change. But for me data2 
>>>>>>> changes, even though it is never written to.
>>>>>>
>>>>>> This is a bug.
>>>>>
>>>>> Yes. And the bug is either
>>>>> - that `void` initialization of `bool` is `@safe`.
>>>>> - that `void` initialization of `bool` can produce a value 
>>>>> that is both `true` and `false`.
>>>>> - that boolean values are assumed to be either `true` or 
>>>>> `false` in @safe code.
>>>>>
>>>>> Which one seems most plausible to you?
>>>>
>>>> None of them. Code generation is incorrect for boolean 
>>>> values.
>>>> ...
>>>
>>> That's the second option above... And I already explained why 
>>> that answer is not satisfactory.
>> 
>> It's not limited to void initialization, so no...
>
> That complaint makes no sense. `void` initialization is a most 
> general way to mess with `bool` memory.

It is not a complaint, it is a fact. You can set bool to be a 
different value. Disabling void initialization in @safe is just a 
bandaid for the larger problem. If you fix code generation, then 
you won't have instances where it appears as though the value is 
both true and false.

>> More accurately code generation is incorrect for bools.
>> ...
>
> You can't blame a data type for having invariants.
>
>>>>>> It seems it doesn't do bounds checking for the index 
>>>>>> because it is a bool value and it is less than the static 
>>>>>> type. If you change the array to a ____dynamically 
>>>>>> allocated____ one, an assert is hit as expected.
>>>>>
>>>>> That's not expected, this is just the compiler not being as 
>>>>> smart as it could be given the available information.
>>>>
>>>> A value is used that is out of bounds of the array, yes that 
>>>> assert is expected.
>>>
>>> The compiler is able to derive that it is not out of bounds...
>> 
>> Not for dynamic arrays, which is what we are talking about.
>
> You have never shown your code but I assume it is something 
> like:

Why are you assuming anything? You are just assuming how it was 
implemented to fit your argument, which is obviously biased. The 
code he posted used a static global, it would only make sense to 
also use a static global.

> data=new int[](2);
> bool b=void;
> data[b]++;
>
> You can plainly see that the length of `data` is 2. So can a 
> compiler (possibly after inlining, if data is a global dynamic 
> array and your data[b]++ is in a static function). And anyway, 
> if the compiler assumes that a value is either 0 or 1 and this 
> fails to be the case, you have UB on your hands and you can't 
> expect anything in particular to happen.

At the very least an assert should be thrown. If the compiler 
doesn't generates assembly that uses the full byte contents of 
the bool, it should be checking that it is within bounds. In 
regards to an array being accessed, that is defined behavior.