Use a trait-object representation also for BytesMut?

[Matthias247]

I really like the approach that had been taken with #294 and #298. That makes it feasible to wrap arbitrary buffers with Bytes as long as they can be cloned, and should allow for custom allocator support. That allows for use-cases like the following: The actual buffers are all managed by a pool, which preallocates and lays out the buffers in a contigous fashion for registered IO or AF_XDP. Whenever IO is performed a buffer from the pool is taken and used for the read operation. When it completes the buffer is wrapped in Bytes and handed to the user. When the user is done with it, it would automatically return to the pool.

However those buffers are all immutable. Is there any plan to also introduce a mutable version of this?
E.g. in order to let the user get a mutable buffer from the pool, allow them to fill the buffer, and then to submit it via an IO operation?

I think for those use-cases we do not necessarily need to have the "growing" functionality that BytesMut currently has. A fixed capacity buffer which is splittable into multiple chunks and mergable later on again is sufficient. It would be also fine and even appreciated if unsplit returns "not unsplittable / None" instead of trying to perform allocations. So maybe that should have a different name - if it's in scope at all.

Semi-related questions:

• The vtable constructor on Bytes is currently not public. Will it stay that way, or is that just temporary in order to stabilize the API?
• Have you thought about adding things like split/unsplit to the vtable instead of directly performing them? I am unsure whether it is needed, since the clone always refers to the full buffer object and the slicing just points to different offsets. But maybe for some implementations it would be helpful.

[carllerche]

Thanks for the kind words 👍 I'm happy that you like the direction.

BytesMut was not moved to a trait-object because I see it as far less critical in terms of being a point of interopt. I think it is far easier for callers to use which ever mutable byte strategy is a best fit and then "freeze" it to a Bytes handle and pass that around. In fact, there was some discussion about whether or not BytesMut should be removed from the crate entirely, but we opted to keep a basic implementation for now.

The vtable constructor on Bytes is currently not public.

The intent is to make it public at some point. @seanmonstar can talk more about the time line I believe.

Have you thought about adding things like split/unsplit to the vtable instead of directly performing them?

Briefly, but didn't see a reason to move it, so we opted to punt.

[seanmonstar]

I mostly didn't make the vtable constructor stuff public yet because I wasn't sure if we'd want to add more methods to it, and how to make a less-gross constructor. But maybe there's nothing to do there, and it should just be made public.