Exploring Dynamic Dispatch in Rust (2017)
alschwalm.com
alschwalm.com
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.
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.
For a more thorough take, I recommend "A tour of `dyn Trait`" ( https://quinedot.github.io/rust-learning/dyn-trait-overview.... )
function zero_filled_int_array(length: usize): int[length] {
...
}
You also might be interested in this old RFC for Rust, which described something similar https://github.com/PoignardAzur/placement-by-return/blob/pla...
1. erased types (have to use behind pointer, so not shallow dynamic sizing) 2. Existential types
So we can build vtables by hand.
Type safe API to any OOP ABI + tons of stuff OOP people never imagined....let's go!
What prevents one from using a pointer like this already? I'm curious.
> 2. Existential types
Fair, I think.
> So we can build vtables by hand. > > Type safe API to any OOP ABI + tons of stuff OOP people never imagined....let's go!
Is this not already possible?
It is, the anyhow crate does this, for example. It does require unsafe though.
How does &dyn MyTrait, which already exist today, not fit the description?
> 2. Existential types
What is that?
fn goose_iterator() -> impl Iterator<Item=Goose>
That type on the right hand side, impl Iterator<Item=Goose> isn't the name of an actual type, that's just a claim about a property of this type, whatever it is. That's an existential type, the type exists, but we're not naming it.
In Rust this means goose_iterator() has some specific result type, but we're not allowed to know what that type is exactly (the compiler knows but our program does not), the only thing we're promised is that whatever type it is, does implement this trait with these parameters.
You'll see this often with things that return a callable - it's literally not possible to name most of Rust's callables, even though they each have a distinct type you can't utter the name of that type. So we need to use existential types for that case, but you can use them (as I did) to promise only that you're giving back an iterator without nailing down specifically which iterator that is - which would let you swap that iterator in an API without causing an API incompatibility.
Yes, but it is still quite limited: they are not yet supported as associated type in traits or in type aliases.
Composition over inheritance is the suggested principle.
A type implementing multiple traits is fine and normal, as is a type bound that requires type parameters to implement multiple traits; none of this poses any "diamond inheritance" type issues or other conceptual problems. It's only if you want to do dynamic dispatch in this situation that there are problems, because dynamic dispatch requires vtables and it's not clear how vtables for multiple traits would work; all known design proposals have serious drawbacks.
The examples don't compile without using Rust edition 2018 or older.