Struct inheritance

[Derek Fawcus]

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?