Is there any reason for `LinkedList` to require `Sized`

I want to implement dynamic delivery of messages in my system. Given, that I don't know how many parts will be registered, I decided to go with BTreeMap<TypeId,...>, so that user facing code is generic, while internals are dynamic.
Message inbox therefore should be dyn Any which can only reasonably reside in an allocation, so I want to put (DestAddrType,dyn Any) into LinkedList, but it doesn't seem to support unsized values...

1 Like

What would it store if it has no size? What would be returned if there is nothing stored?

Common approaches to solve this are to store a reference or some form of boxing the type: &dyn Trait or Box<dyn Trait>.

1 Like

I think the internal Node<T> holding the value could be unsized, since it is always allocated. However, push operations that take values would have to be generic on U: Unsize<T>, which is an unstable trait, and there's no way to give the value back in pop, unless we Box it perhaps.

One option would be to expose the node type somehow -- it'd work much like Box, but it'd have the extra space for the pointers in it, so that if you own a node you could infallibly add it to a LinkedList, and it's what you'd get back when you pop something. That'd mean no deallocation in pop_node() either, which is kinda nice for reuse potential.


CursorMut also has remove_current_as_list, which is an indirect way of exposing Node.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.