Can we just have struct inheritence already?

[Timon Gehr]

On 14.06.19 23:16, Exil wrote:
> 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 disagreed with my assessment, so it is a complaint. Look it up. 
There is really no basis for attacking my statement for not being 
general enough, as it referred to the compiler's behavior on a specific 
code sample.

> You can set bool to be a different value.

Not in a @safe way.

> Disabling void initialization in @safe is just a bandaid for the 
> larger problem.

No. The "larger problem" is that assigning random data to memory 
occupied by a data type with an invariant can lead to UB. @safe prevents 
UB, while in @system/@trusted code it is your own responsibility, so 
this actually solves the 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?

Because you didn't provide it.

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

Which I have considered, so your biased "obviously biased" accusation is 
obviously wrong. I will try to stop replying to your posts as they are 
anonymous, of poor quality and may actually be written in bad faith. 
(How likely is it that you would get essentially _every single thing_ 
horribly wrong?)

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

Of course not. You have an array of length 2 and are indexing it with a 
`bool`! Throwing a bounds error is never the right thing to do here. If 
you say `bool` has no invariant and everything except '\0' represents 
true, then conversion of `bool` to `size_t` needs to be implemented as 
`(b?1:0)`.

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

If the `bool` has an invariant that says it is always either `0` or `1`, 
then using a `void`-initialized `bool` is UB.