<i>> Even though DebugAny inherits from Any</i><p>I'm going to push back against this terminology for the sake of people who don't know Rust and are coming from traditional OO languages.<p>Rust traits don't "inherit" from other traits, they "require" other traits.<p>So if I have two traits, where one requires the other:<p><pre><code> trait Foo {}
trait Bar: Foo {}
</code></pre>
That doesn't add Foo's methods to Bar's list of methods, like you might expect from the term "inheritance".<p>Instead, it just means that it's not possible to implement Bar for a type unless Foo is also separately implemented for that type.<p>Despite this it's still accurate to say that this enables a supertype/subtype relationship in certain contexts, but be careful because Rust isn't a traditionally OO language, so that may not always be the most useful framing.
The important change here appears to be that the internal representation of a vtable is now guaranteed to have its supertraits laid out in some predictable prefix form to its own methods.<p>EDIT: or if this is not possible, a pointer to the appropriate vtable is included. I assume this must be for diamond trait inheritance.
This example shows how it works for one trait, Debug, but what if you have a type that (might) implement multiple traits A, B, and/or C? It isn't clear to me if that is possible, unless the type implements all of those traits. What I'd like to do is have some base trait object and query it to see if it supports other interfaces, but also not have to have stub "I don't actually implement this" trait impls for the unsupported ones. A bit like how I might use dynamic_cast in c++.<p>(I believe I understand that in rust this has not historically been possible because rust doesn't have inheritance, so, there can be only one vtable for a type, rather than an chain like you might have in c++.)