Can we just have struct inheritence already?

[Exil]

On Thursday, 13 June 2019 at 21:08:42 UTC, Timon Gehr wrote:
> On 13.06.19 22:20, Exil wrote:
>> On Thursday, 13 June 2019 at 19:51:12 UTC, Timon Gehr wrote:
>>> On 13.06.19 21:44, Walter Bright wrote:
>>>> On 6/13/2019 4:30 AM, Timon Gehr wrote:
>>>>> Yes. IMHO this shouldn't be a @safe pure operation.
>>>>
>>>> D regards converting a pointer to an int as safe, but not 
>>>> the other way around.
>>>
>>> I know, and that is fine, but casting a pointer to int is not 
>>> pure. It glances into the global state maintained by the 
>>> memory allocator.
>> 
>> The operation is pure.
>
> No.

What global state is it accessing then? If you remove the new 
allocate and just use a passed in pointer parameter.

>> Accessing global state is the part that is not pure. For 
>> convience I guess you can allocate memory, ...
>
> It's an _abstraction_. You allocate because you need memory to 
> represent your values, not because you want to know at which 
> address your values will be located. The former is a necessity, 
> the latter is not pure.
>
> Purely functional programming languages also allocate memory at 
> runtime, but it is hidden in the runtime system and kept 
> separate from the language definition. In D, user code and 
> runtime system can both be in the same code base, but the 
> runtime system parts need to be in impure or pure @system code, 
> not in your pure code.

Yes, that is not pure. It's a compromise for usability.

>> ... > Pure for the most part guarantees you don't
>> access global variables.
>
> No, it does not. It guarantees you don't read or write implicit 
> state (i.e. state not accessible through the function 
> arguments).

Tomato tomato.

>> Pure doesn't mean deterministic.
>
> Yes, it does. A function can only fail to be deterministic if 
> it accesses implicit state that changes between function 
> invocations.

Which gets violated anyways because of the GC.