Why can’t `&(?Sized + Trait)` be cast to `&dyn Trait`?

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 is Sized, the compiler knows statically what vtable it should use to create the trait object;
  • If T is dyn 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 not dyn Foo, even though the trait is object safe, there is no vtable for impl 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 the Foo 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

Leave a Comment