0

I have this code:

fn main() {
    let p = Person;
    let r = &p as &dyn Eatable;

    Consumer::consume(r);
    // Compile error
    Consumer::consume_generic(r);
}

trait Eatable {}

struct Person;

impl Eatable for Person {}

struct Consumer;

impl Consumer {
    fn consume(eatable: &dyn Eatable) {}
    fn consume_generic<T: Eatable>(eatable: &T) {}
}

Error:

the size for values of type dyn Eatable cannot be known at compilation time

I think it is strange. I have a method that literally takes a dyn Eatable and compiles fine, so that method knows somehow the size of Eatable. The generic method (consume_generic) will properly compile down for every used type for performance and the consume method will not.

So a few questions arise: why the compiler error? Are there things inside the body of the methods in which I can do something which I can not do in the other method? When should I prefer the one over the other?

Sidenote: I asked this question for the language Swift as well: Differences generic protocol type parameter vs direct protocol type. In Swift I get the same compile error but the underlying error is different: protocols/traits do not conform to themselves (because Swift protocols can holds initializers, static things etc. which makes it harder to generically reference them). I also tried it in Java, I believe the generic type is erased and it makes absolutely no difference.

J. Doe
  • 12,159
  • 9
  • 60
  • 114

1 Answers1

1

The problem is not with the functions themselves, but with the trait bounds on types.

Every generic types in Rust has an implicit Sized bound: since this is correct in the majority of cases, it was decided not to force the developer to write this out every time. But, if you are using this type only behind some kind of reference, as you do here, you may want to lift this restriction by specifying T: ?Sized. If you add this, your code will compile fine:

impl Consumer {
    fn consume(eatable: &dyn Eatable) {}
    fn consume_generic<T: Eatable + ?Sized>(eatable: &T) {}
}

Playground as a proof

As for the other questions, the main difference is in static vs dynamic dispatch.

When you use the generic function (or the semantically equivalent impl Trait syntax), the function calls are dispatched statically. That is, for every type of argument you pass to the function, compiler generates the definition independently of others. This will likely result in more optimized code in most cases, but the drawbacks are possibly larger binary size and some limitations in API (e.g. you can't easily create a heterogeneous collection this way).

When you use dyn Trait syntax, you opt in for dynamic dispatch. The necessary data will be stored into the table attached to trait object, and the correct implementation for every trait method will be chosen at runtime. The consumer, however, needs to be compiled only once. This is usually slower, both due to the indirection and to the fact that individual optimizations are impossible, but more flexible.

As for the recommendations (note that this is an opinion, not the fact) - I'd say it's better to stick to generics whenever possible and only change it to trait objects if the goal is impossible to achieve otherwise.

Cerberus
  • 8,879
  • 1
  • 25
  • 40