Bytes/BytesMut vs Buf/BufMut is confusing in terms of naming about bytes HOT 7 CLOSED

I'd like to make the case for providing an impl Buf for Bytes.

I also expected the BytesMut : BufMut, Bytes : Buf symmetry to hold when I first started working with the crate. For my usecase of Bytes, which is decoding data structures, it would be extremely handy to have the Buf implementation built-in to Bytes, instead of having to wrap in a Cursor.

Towards that end, I put together a proof-of-concept showing that Buf can be implemented for Bytes using nothing but the current public API. The PoC is not meant to be an efficient implementation, but instead to prove that it can be done.

cc @carllerche

from bytes.

I had some thoughts on how to impl it while avoiding the allocation. I'll try to work on it.

However, the changes of types for the associate types of trait impls can't change until 0.5 :(

from bytes.

However, the changes of types for the associate types of trait impls can't change until 0.5 :(

I don't think those changes were strictly necessary, but it would be a nice simplification in the long run.

from bytes.

Has reserving the first 4 or 8 bytes of the allocated buffer for the reference count been considered? This would 'waste' 4 or 8 bytes in the non-shared case, but it cuts down an allocation in the shared case. I think it would also make efficiently impl'ing Buf easier.

from bytes.

#166 provides the advance function for Bytes and BytesMut. This unblocks implementing Buf for these two types. The actual implementation of Buf has to be done in 0.5.

from bytes.

Is this still true if Bytes impls Buf and BytesMut impls BufMut?

from bytes.

Shouldn't this be closed? In 0.5.x:

• Buf is implemented for Bytes and for BytesMut.
• BufMut is implemented for BytesMut

from bytes.