Struct inheritance

[Jonathan M Davis]

On Thursday, December 5, 2024 6:13:04 PM MST Richard (Rikki) Andrew Cattermole 
via dip.ideas wrote:
> Problem is, template parameters also should work, using ``Child :
> Parent`` syntax.
>
> Otherwise the usability on this is going to be absolutely atrocious in
> meta-programming.

: tests for implicit conversions. That's all it ever does, and making it do
anything else will introduce inconsistencies into the language. For
instance, since struct inheritance would _not_ involve an implicit
conversion, how would you test for an implicit conversion if is(T : U) were
true because T inherited from U? After all, since we're unfortunately not
actually going to get rid of alias this, it would be quite possible to have
T inherit from U an then have an alias this which makes it implicitly
convert to U.

Code that wants to test for struct inheritance can do so with a template
constraint and a __traits trait just like plenty of other code does. There's
nothing special about inheritance, let alone struct inheritance that makes
it any different.

Also, honestly, I don't think that testing for struct inheritance with
metaprogramming is even likely to be a valid use case outside of niche
situations. There is no conversion unless the programmer explicitly adds
one, so a "child" type can't be treated as if it were the same as its
"parent" type, and if templated code wants to use the API of the parent
struct so that it works with any struct type that's derived from it, it's
arguably better to test its API and not anything inheritance-related,
because it's the API that actually matters for using it, not whether that
API was inherited from a particular struct. And if it's the API that's
tested, then it can work with any type with that API regardless of whether
it's derived from a particular struct.

Really, if struct inheritance does not involve implicit conversion, then I
don't think that there's much reason to even care that that relationship
exists. They're just two types which happen to have some of the same
members, and if they need to be used by the same code, it's going to need to
be templated just like happens with any two unrelated types which share
enough of the same API to be duck typed together. And there's no need to
take the inheritance into account at all with that code. It's simply the API
that matters, not where the implementation happens to have come from.

Either way, given that : is specifically for testing implicit conversions,
it's really not appropriate to conflate it with inheritance when implict
conversions aren't involved. And even for class inheritance, which has the
implicit conversion, it's arguably a mistake to use it to test for
inheritance, because it's testing for an implicit conversion, not
inheritance, and the implicit conversion can be there for other reasons. So,
in general, we should be moving away from using is(T : U) to test for
inheritance of any kind, not making struct inheritance use it too.

- Jonathan M Davis