Hacker News Reader

Comment by sshine | Hacker News Reader

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

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

View on HN

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

You have likely used dyn result, possibly without realising it, if you have used anyhow

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

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

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.

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.

Reply on news.ycombinator.com