Yes. In the reference, below the definition, there is a list of examples of:
- Traits that are object-safe with object-safe methods
- Traits that are object-safe with non-dispatchable methods
- Traits that are not object-safe
https://doc.rust-lang.org/reference/items/traits.html#object...> you can make a `Vec<YourType>` as long as `YourType` does not implement any non-object-safe methods?
It is traits that are object safe, not concrete types.
You cannot make a `Vec<YourTrait>`, you have to make a `Vec<T> where T: YourTrait` or a `Vec<Box<dyn YourTrait>>` or similar.
You only need object safety if you're passing around values dynamically cast to a trait. That's not a required programming pattern.
Yep. In 3+ years of writing rust full time, I’ve still never used `dyn Trait` in any of its forms. A vec where every item is independently heap allocated? Why? And yikes! That would perform terribly.
Just because that's the example given (by someone who's trying to understand the concept, no less) doesn't mean that that's the only thing that the language feature is usable for.
Trait objects (read: runtime polymorphism) have their pros and cons just as generics (read: parametric polymorphism) have theirs. Not everything can be known at compile time, and that's perfectly okay.
It kind of makes me we wish there was a keyword that would grab all implementations of that trait being compiled and do the same thing though. At least for a statically linked codebase it could figure out all the sizes of the implementations
But it would be nice if there was some unification of the idea of an enum where every variant implements a trait and &dyn Trait. Basically, an enum made up of a set of named structs where each struct implements a specific trait could be a lovely concept.
I used to care so much about this stuff then I learned to not give a sh*t and Arc<dyn Trait> to get stuff done. If you use a service oriented architecture with interfaces to reduce coupling this is the way.