Struct inheritance
Jonathan M Davis
newsgroup.d at jmdavisprog.com
Fri Dec 6 00:14:48 UTC 2024
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
More information about the dip.ideas
mailing list