Struct inheritance

[Richard (Rikki) Andrew Cattermole]

On 06/12/2024 1:14 PM, Jonathan M Davis wrote:
> On Thursday, December 5, 2024 4:10:46 PM MST Richard (Rikki) Andrew Cattermole
> via dip.ideas wrote:
>>> After that talk, I discussed struct inheritance briefly with Walter, and
>>> his idea was that if we did it, there would be _no_ conversions of any
>>> kind that came from it. It would purely be a way to have a struct inherit
>>> all of the fields and member functions from the "parent" struct and as
>>> such would essentially be the compiler copying and pasting that code into
>>> the struct doing the inheriting.
>>>
>>> So, it would provide a way to inherit / copy the implementation, but the
>>> types would be completely divorced from one another in terms of how they
>>> were used.
>>>
>>> Personally, I think that that's the right approach, since it's the issues
>>> around implicit conversions that are the core problem with alias this, and
>>> it avoids all issues with regards to slicing objects (which is the primary
>>> reason why classes in D are on the heap instead of on the stack like they
>>> can be in C++).
>>>
>>> - Jonathan M Davis
>>
>>   From my perspective that is mostly an implementation detail.
>>
>> The reason it is not fully an implementation detail is due to methods
>> effectively having what I've been calling ``@reinterpretAsChild`` turned on.
>>
>> We can still make overrides, and is expression to check if it inherits
>> from the parent type to work.
>>
>> I'm ok with this approach. It simplifies a bunch of problems down.
> 
> What isn't an implementation detail is that what Walter proposed would
> involve _zero_ conversions. So, there would be no casting to a parent from a
> child or vice versa unless you explicitly implemented casts for that. With
> what Walter was looking to do with struct inheritance, it would not be
> creating at type hierarchy at all. It would purely be a way to copy the
> implementation. So, there would nothing like @reinterpretAsChild. The types
> would effectively be unrelated to one another as far as the type system was
> concerned. And if we _did_ have some sort of is expression to test whether
> one struct inherited from another, it couldn't be the same one that's used
> for classes, because there is no conversion (though honestly, the fact that
> we test for inheritance via implicit conversion with classes is broken given
> the fact that alias this exists).
> 
> - Jonathan M Davis

For the checking of inheritance what I mean is:

``is(Child : Parent)``

The same as a class has. Something the compiler certainly has the 
ability to offer.

For casting, you could only do it via pointers in ``@system`` code, you 
can do this today. No way would it be appropriate to add a new form of 
casting. Since there is no vtable or guarantee of heap allocation.

As for ``@reinterpretAsChild`` it would effectively be turned on and 
couldn't be opt-out, and would be a better way of describing this 
behavior as it would exist for classes. Rather than introducing some new 
unique to struct behavior.

This needs a DIP written to make this stuff clear. So that'll be a next 
months job. Because I understand what you're saying and what Walter is 
concerned with based upon your statement. Its just that the spec and the 
implementation are going to have different concerns and they need to be 
aligned for both the end user and for it to be implementable.