It's worth noting that this post is 8 years old, and some things have moved on since then.<p>In particular, trait object upcasting is on beta now and will be promoted to stable in a couple of weeks. I know that there has also been active development towards enabling multiple-bound trait objects, but I don't know what the status of that effort is.<p>The article also makes the (quite understandable) mistake of conflating a fat pointer to a trait object with the trait object itself. In Rust, trait objects are "unsized", which means they can only exist behind some kind of pointer. And any pointer in Rust that targets an unsized type grows an additional metadata field (for trait objects, a vtable pointer). This is a slightly weird behavior with a few unexpected consequences that often catches people off-guard, but understanding it is key to understanding why you can't make a trait object for something like `Clone`, which returns an instance of itself-- Because unsized types can't appear on their own, the return type of the `clone()` method would be invalid.<p>For a more thorough take, I recommend "A tour of `dyn Trait`" ( <a href="https://quinedot.github.io/rust-learning/dyn-trait-overview.html" rel="nofollow">https://quinedot.github.io/rust-learning/dyn-trait-overview....</a> )
Looking forward to when Rust gets<p>1. erased types (have to use behind pointer, so not shallow dynamic sizing)
2. Existential types<p>So we can build vtables by hand.<p>Type safe API to any OOP ABI + tons of stuff OOP people never imagined....let's go!
If I recall correctly, Rust decisively wanted to avoid multiple inheritance concept, in order not to deal with the diamond problem.<p>Composition over inheritance is the suggested principle.
Trait upcasting will land in Rust 1.86.0 which will be released in one week: <a href="https://github.com/rust-lang/rust/pull/134367" rel="nofollow">https://github.com/rust-lang/rust/pull/134367</a>