Hacker News Reader

Comment by palata | Hacker News Reader

It is a nice read!

I am not super familiar with the definition of "object-safe" (I read the docs but the definition is not completely trivial for me).

Does it work to say that an "object-safe" method mutates the object? That's what happens when you take `&mut self`, right?

But if I understood this correctly, I guess it means that a function without side-effect in Java should not really count as a method? Because in Java I call it a method whether it has a side-effect or not. Which corresponds exactly to the definition of `method` in the Rust docs, I think [1]. In C++, I would think that this is the difference between a const (no side-effect) and a non-const (side-effect) method.

[1]: https://doc.rust-lang.org/reference/items/associated-items.h...

View on HN

It has to do with type erasure and knowing how big a type is in memory, not mutation. With traits, you can erase the implementing type and get back a vtable of a trait's method - called a trait object.

A trait is object-safe as long as no trait method returns the implementing type (like T::clone() -> T). Once it's a trait object, T is no longer known and the compiler doesn't know how much memory to allocate on the stack or heap, which makes it impossible to use. That's why trait objects have to be boxed or behind references - all pointers have a known size.

> A trait is object-safe as long as no trait method returns the implementing type (like T::clone() -> T)

That, and much more: https://doc.rust-lang.org/reference/items/traits.html#object... .

This is the shortest, clearest explanation I've yet seen of object safety. Thanks.

Not every trait can be made into a trait object. Traits that are "object safe" can be made into a trait object. Nothing to do with mutation, or side effects.

hmm... so there are object-safe methods and non-object-safe methods, and you can make a `Vec<YourType>` as long as `YourType` does not implement any non-object-safe methods?

Yes, except that you need a layer of indirection to make a trait object, so like Vec<Box<YourTrait>> or similar.

You might be confusing types and traits (typeclasses) here; it's not about `YourType` but rather when you want to make a Vec of heterogenous types that share a trait. That's when the question of object safety (and needing a vtable) arises.

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

> 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