Struct inheritance
Derek Fawcus
dfawcus+dlang at employees.org
Thu Dec 5 23:36:17 UTC 2024
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?
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?
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?
More information about the dip.ideas
mailing list