3

I need a struct that contains a trait object and more of itself. Disappointedly the following code does not compile: 

trait Foo {}

struct Bar<T: Foo> {
    bars: Vec<Box<Bar<dyn Foo>>>,
    foo: T,
}

I managed to coerce this into compiling by adding the ?Sized bound to T, but I do not understand why this should be the case. I assume this is because all trait objects have the same size, but the size of Bar depends on the size of the concrete type T. If so, how is Bar with an unsized T represented in memory? Specifically what tracks its size on the heap and why can not this mechanism be used in the sized case.

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
Maciej Goszczycki
  • 1,118
  • 10
  • 25
  • 3
    It seems to me that you would want `Bar`s of `Box`es rather than `Box`es of `Bar`s. Switching these ought to fix the issue. – E_net4 Aug 05 '18 at 08:58
  • I have considered this approach but `Box` does not implement `Foo`. In reality `Foo` is a a larger trait and and implementing everything for a `Box` would be a chore. One option is switching the bound for _T_/`::new` to `AsRef` which works but is not quite as neat. – Maciej Goszczycki Aug 05 '18 at 11:10
  • *but `Box` does not implement `Foo`* — [so implement it...](https://stackoverflow.com/q/33041736/155423). – Shepmaster Aug 05 '18 at 13:37
  • In reality `Foo` is sizeable trait and implementing a it would not only be a chore, but also feels like something the compiler should be able to handle. – Maciej Goszczycki Aug 05 '18 at 13:40

1 Answers1

0

The type dyn Foo does not have a size known at compile time. So when you write Bar<dyn Foo>, the compiler won't allow it because (by default) type parameters must be sized. The compiler suggests that you fix this by allowing T to be unsized, which is necessary for T to be dyn Foo.

how is Bar with an unsized T represented in memory?

A struct is allowed to have at most one unsized field. Its data is then laid out in memory with the sized fields first, and then the unsized field last. This restriction means that relative memory addresses of all fields can be known at compile-time. A struct with a ?Sized type parameter can itself be either sized or unsized, depending on the concrete type of its argument. When the struct is unsized, it can't go on the stack so you can only use it from behind a pointer.

There is currently no documentation for this kind of object. It's not exactly a trait object, but it's a pointer to something that may not be sized. As your example shows, this works. But I cannot tell you where the vtable pointer is stored because I don't know, and I'm not sure how to find out.

Specifically what tracks its size on the heap and why can not this mechanism be used in the sized case.

The size of each object doesn't actually change - it's just potentially different per instance. The mechanism can be used "in the Sized case", but you don't have a sized case! Even for a T that is sized, the bars collection will contain boxes of Bar<dyn Foo> which are unsized. That's why you need to T: ?Sized (as opposed to T: !Sized), to say that this type works for T being either sized or unsized.

Peter Hall
  • 53,120
  • 14
  • 139
  • 204
  • _However, this is unlikely to be what you really want, since you have a T field in the struct, which must be sized_ That was my initial thought but what surprised me is that this seems to work fine?! I assume that in practice the compiler fails if _T_ is an unsized type even with `?Sized` bound. Example [playground](https://play.rust-lang.org/?gist=cfdc32f082fb502777e828ef4ac9c04e&version=stable&mode=debug&edition=2015). – Maciej Goszczycki Aug 05 '18 at 11:19
  • You'll get an error if you try to actually _use_ an unsized type there. – Peter Hall Aug 05 '18 at 11:22
  • Which is fine since I don't actually want to pass any unsized types. Although I still don't understand why adding `?Sized` should be necessary for `Box>` to work. – Maciej Goszczycki Aug 05 '18 at 11:26
  • @mgoszcz2 That's because the type `dyn Foo` is not `Sized`. – E_net4 Aug 05 '18 at 11:29
  • This brings me back to original question. What tracks the physical heap size of a boxed `Bar`? Is it just that all trait objects, being only vtables, have the same size? – Maciej Goszczycki Aug 05 '18 at 11:32
  • Nothing tracks the physical heap sized of a boxed `Bar`. If you try to construct one, you'll find out that you can't. – Peter Hall Aug 05 '18 at 11:59
  • What happens in that playground then. ([Link for connivance](https://play.rust-lang.org/?gist=cfdc32f082fb502777e828ef4ac9c04e&version=stable&mode=debug&edition=2015)) – Maciej Goszczycki Aug 05 '18 at 12:04
  • Ok, this actually makes sense - I just didn't know this was allowed. When you construct a `Bar`, its size is known because you use a concrete type. Each `Bar` could have a different size, which still works because they are boxed. – Peter Hall Aug 05 '18 at 12:52
  • And the `?Sized` is required for the inner `Bar`s in the `Vec`. – Peter Hall Aug 05 '18 at 12:55
  • I assume that `Bar` is then a normal `Bar` with the two pointer trait object (`std::raw::TraitObject`) as _T_. I guess in this case `?Sized` means "well it's a trait object" not actually without a defined size. – Maciej Goszczycki Aug 05 '18 at 13:00
  • `dyn Trait` really is without a defined size. `&dyn Trait` and `Box` both have a size, but that's just the size of the pointer. `Bar` is also unsized, until you put in in a box. – Peter Hall Aug 05 '18 at 13:02
  • I have updated the answer, hopefully to reflect your actual question better – Peter Hall Aug 05 '18 at 13:12
  • Thanks. There is still one thing I'm not clear on. `Box` is a pointer to a trait object on the heap. How is `Box>` represented? Does the box point to `Foo` and type of field `foo` becomes a trait object? If not where is the trait object stored and what does `foo` become? – Maciej Goszczycki Aug 05 '18 at 13:26