the article isn't very good for anyone not already familiar with the problem
What I'd like to do is have some base trait object and query it to see if it supports other interfaces
rust doesn't have inheritance
rust traits and lifetimes have inheritance, kinda, (through rust types do not)
E.g. `trait A: Debug + Any` means anything implementing A also implements Debug and Any. This is a form of interference, but different to C++ inheritance.
This is why we speaking about upcasts when casting `&dyn A as &dyn Debug` and downcast when trying to turn a `&dyn A` into a specific type.
But because this inheritance only is about traits and the only runtime type identifying information rust has is the `Any::type_id()` the only dynamic cast related querying you can do is downcasting. (Upcasting is static and possible due to changes to the vtable which allow you to turn a `&dyn A` vtable into a `dyn Any`/`dyn Debug` vtable (in the example below).
The part of bout downcast form the article you can ignore, it's some nice convenient thing implicitly enabled by the upcasting feature due to how `downcast_ref` works.
So I think what you want might not be supported. It also is very hard to make it work in rust as you would conceptually need a metadata table for each type with pointer to a `dyn` vtable for each object safe trait the type implements and then
link it in every vtable. The issue is concrete rust traits can
be unbound e.g. a type `C` might implement `T<bool>` and `T<T<bool>>` and `T<T<T<bool>>>` up to infinity :=) So as long as you don't have very clever pruning optimizations that isn't very practical and in general adds a hidden runtime cost in ways rust doesn't like. Like e.g. if we look at `dyn T` it e.g. also only contains runtime type information for up casting if `T: SomeTrait` and downcasting if `T: Any` and the reason up casting took like 5+ years is because there are many subtle overhead trait offs between various vtable representations for `C: A+B` which might also affect future features etc.
Comments
the article isn't very good for anyone not already familiar with the problem
rust traits and lifetimes have inheritance, kinda, (through rust types do not)
E.g. `trait A: Debug + Any` means anything implementing A also implements Debug and Any. This is a form of interference, but different to C++ inheritance.
This is why we speaking about upcasts when casting `&dyn A as &dyn Debug` and downcast when trying to turn a `&dyn A` into a specific type.
But because this inheritance only is about traits and the only runtime type identifying information rust has is the `Any::type_id()` the only dynamic cast related querying you can do is downcasting. (Upcasting is static and possible due to changes to the vtable which allow you to turn a `&dyn A` vtable into a `dyn Any`/`dyn Debug` vtable (in the example below).
The part of bout downcast form the article you can ignore, it's some nice convenient thing implicitly enabled by the upcasting feature due to how `downcast_ref` works.
This https://play.rust-lang.org/?version=beta&mode=debug&edition=... might help.
So I think what you want might not be supported. It also is very hard to make it work in rust as you would conceptually need a metadata table for each type with pointer to a `dyn` vtable for each object safe trait the type implements and then link it in every vtable. The issue is concrete rust traits can be unbound e.g. a type `C` might implement `T<bool>` and `T<T<bool>>` and `T<T<T<bool>>>` up to infinity :=) So as long as you don't have very clever pruning optimizations that isn't very practical and in general adds a hidden runtime cost in ways rust doesn't like. Like e.g. if we look at `dyn T` it e.g. also only contains runtime type information for up casting if `T: SomeTrait` and downcasting if `T: Any` and the reason up casting took like 5+ years is because there are many subtle overhead trait offs between various vtable representations for `C: A+B` which might also affect future features etc.