Can we just have struct inheritence already?

[Timon Gehr]

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.

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