This problem can be reduced to the following simple example (thanks to turbulencetoo):
trait Foo {}
fn make_dyn<T: Foo + ?Sized>(arg: &T) -> &dyn Foo {
arg
}
At first glance, it really looks like this should compile, as you observed:
- If
T
isSized
, the compiler knows statically what vtable it should use to create the trait object; - If
T
isdyn Foo
, the vtable pointer is part of the reference and can just be copied to the output.
But there’s a third possibility that throws a wrench in the works:
- If
T
is some unsized type that is notdyn Foo
, even though the trait is object safe, there is no vtable forimpl Foo for T
.
The reason there is no vtable is because the vtable for a concrete type assumes that self
pointers are thin pointers. When you call a method on a dyn Trait
object, the vtable pointer is used to look up a function pointer, and only the data pointer is passed to the function.
However, suppose you implement a(n object-safe) trait for an unsized type:
trait Bar {}
trait Foo {
fn foo(&self);
}
impl Foo for dyn Bar {
fn foo(&self) {/* self is a fat pointer here */}
}
If there were a vtable for this impl
, it would have to accept fat pointers, because the impl
may use methods of Bar
which are dynamically dispatched on self
.
This causes two problems:
- There’s nowhere to store the
Bar
vtable pointer in a&dyn Foo
object, which is only two pointers in size (the data pointer and theFoo
vtable pointer). - Even if you had both pointers, you can’t mix and match “fat pointer” vtables with “thin pointer” vtables, because they must be called in different ways.
Therefore, even though dyn Bar
implements Foo
, it is not possible to turn a &dyn Bar
into a &dyn Foo
.
Although slices (the other kind of unsized type) are not implemented using vtables, pointers to them are still fat, so the same limitation applies to impl Foo for [i32]
.
In some cases, you can use CoerceUnsized
(only on nightly as of Rust 1.36) to express bounds like “must be coercible to &dyn FooTrait
“. Unfortunately, I don’t see how to apply this in your case.
See also
- What is a “fat pointer” in Rust?
- Use trait object to pass str in rust has a concrete example of a reference to an unsized type (
str
) that cannot be coerced to a reference to a trait object.