Struct inheritance

[Jonathan M Davis]

On Thursday, December 5, 2024 4:36:17 PM MST Derek Fawcus via dip.ideas wrote:
> On Thursday, 5 December 2024 at 22:41:25 UTC, Jonathan M Davis
>
> 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++).
>
> So if I read that correctly, for the latter code example I gave,
> assuming use of structs rather and classes, and adjusted...
>
> The 'Assign' case would be a compile error, and once removed it
> would yield:
>
> ```
> MethB(P) Direct Parent
> MethC(P) Direct Parent
>
> MethB(P) Inherit Child
> MethC(C) Inherit Child
> ```
>
> Is that correct?

The types would be completely independent from one another. It would just be
a way to copy the implementation from one to the other. So, no conversions
or assignments would ever take place without some explicit code handling it,
just like normally occurs with any two types which have nothing to do with
one another. It's purely an inheritance of implementation and would not
create a hierarchy like you get with classes. So, it would therefore avoid
all of the various issues that you get with class inheritance and objects on
the stack in C++ - but it also wouldn't get any form of polymorphism. It
would just be a way to share code.

> Also is it the case that method overrides would dominate over any
> 'pasted' method from the parent - i.e. the MethC case?  Or would
> those be forbidden as a name conflict?

IIRC, from what Walter said, if the child implemented the same member
function as the parent, the child's would take precedence, and the parent's
would basically not exist in the child.

> Presumably one could not have data fields with the same name in
> the Parent and Child, or would there be a rule for resolving that
> conflict?

I didn't discuss that particular issue with Walter, so I don't know what his
stance would be, but the most obvious thing would presumably be to just make
it illegal. Particularly when you're dealing with private members, it's not
like it would be a big deal to just name the member variable something else
to avoid the conflict.

We had a fairly quick discussion on some of the obvious issues that I
thought of off the top of my head (e.g. conversions and object slicing), but
it's not like we sat down and hashed it all out in detail. So, if/when
Walter decides to implement it, he'll have to sort that out with a DIP (or
he'll have to approve someone else's DIP where they provide all of those
details).

But the discussion _was_ enough to make it clear that Walter's intention was
to use struct inheritance purely as a way to inherit the implementation and
_not_ as a way to provide any sort of implicit conversions or a way to use
one type as another (though templated code could use duck typing like it
normally does to work with types that have the appropriate API, so you could
have the same code work with multiple struct types that inherited from the
same parent, since they'd all have the API from the parent).

- Jonathan M Davis