Can we just have struct inheritence already?

[Timon Gehr]

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.

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

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

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