Can we just have struct inheritence already?

[Exil]

On Friday, 14 June 2019 at 00:56:11 UTC, Timon Gehr wrote:
> On 14.06.19 02:28, Exil wrote:
>> 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.
>> ...
>
> It's accessing the address, which is dependent on global state. 
> The caller is calling a pure function, so the address of the 
> integer is not conceptually part of the information that is 
> passed to it, it is external state. It's not what the caller 
> signs up for when calling a pure function. It messes with the 
> guarantees that pure is supposed to provide; they should be 
> similar to what you get in pure functional programming 
> languages.
>
>>>> 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.
>> ...
>
> Casting pointers to integers in pure @safe code is not a 
> compromise for usability, it's simply an oversight that needs 
> to be corrected. If you have a good reason to do it, write some 
> pure @trusted code.

Why would you have this feature, that only relates to "pure" only 
work in @safe? I don't think @safe combines with other attributes 
to make them mean something different, nor should it.

>>>> ... > 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.
>> ...
>
> No. Immutable variables are variables. Accessing a global via a 
> ref argument is an access. If you don't care about being 
> precise, please stop wasting my time.
>
>>>> 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.
>> 
>> 
>
> Not if you can't access memory addresses. Do you understand 
> abstraction? Do you have functional programming experience?

This is not a pure functional programming language though. You 
can access pointers, even if the pure function doesn't, it's call 
site could.