Can we just have struct inheritence already?

Exil Exil at gmall.com
Fri Jun 14 00:50:27 UTC 2019


On Friday, 14 June 2019 at 00:49:55 UTC, Exil wrote:
> On Friday, 14 June 2019 at 00:35:10 UTC, Timon Gehr wrote:
>> On 13.06.19 23:45, Walter Bright wrote:
>>> On 6/13/2019 12:51 PM, 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.
>>> 
>>> We had a discussion a while back about whether allocating 
>>> memory via new was pure or not, since a different value was 
>>> produced each time. We eventually took the pragmatic route 
>>> that pure functions would be next to useless if this was not 
>>> allowed.
>>
>> It is obvious that allocation has to be pure. However, 
>> accessing the address of your data is impure.
>> The runtime systems of pure functional languages also allocate 
>> memory, but the addresses are not exposed to the pure user 
>> code.
>
> And you can't return the pointer to something in those 
> languages. It is entirely dependent on the language, this is 
> not a functional language. You can return pointers. What do you 
> do when you expect two calls to have different allocated 
> objects that have the same value? Does the compiler simply 
> produce one object, or two or more?

*pure functional language


More information about the Digitalmars-d mailing list