Can we just have struct inheritence already?

[Timon Gehr]

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.

> 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:

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.