3 ms·

> there are object-safe methods and non-object-safe methods Yes. In the reference, below the definition, there is a list of examples of: - Traits that are o

by sshine 2y ago

> there are object-safe methods and non-object-safe methods 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-safety 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.

josephg 2y ago
> 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.
- guipsp 2y ago
  You have likely used dyn result, possibly without realising it, if you have used anyhow
- filleduchaos 2y ago
  > A vec where every item is independently heap allocated? 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.
- charrondev 2y ago
  I mean if you know all the concrete types ahead of time you can put them in an enum. 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
  - josephg 2y ago
    That would be lovely, but it would give you “spooky action at a distance” where some large struct adding an impl for some trait would change the size of a data structure in another unrelated part of the program. 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.
- Sytten 2y ago
  Its a pointer with a vtable, it wont make a difference in like 99.99% of cases. You very very likely use them because a lot of libraries use them, Box<dyn Error + Send + Sync> is very common. 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.

by sshine 2y ago

josephg 2y ago

> 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.

guipsp 2y ago
You have likely used dyn result, possibly without realising it, if you have used anyhow
filleduchaos 2y ago
> A vec where every item is independently heap allocated? 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.
charrondev 2y ago
I mean if you know all the concrete types ahead of time you can put them in an enum. 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
- josephg 2y ago
  That would be lovely, but it would give you “spooky action at a distance” where some large struct adding an impl for some trait would change the size of a data structure in another unrelated part of the program. 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.
Sytten 2y ago
Its a pointer with a vtable, it wont make a difference in like 99.99% of cases. You very very likely use them because a lot of libraries use them, Box<dyn Error + Send + Sync> is very common. 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.