BytesMut should impl IntoBuf

[carllerche]

See: tokio-rs/tokio-io#72

[seanmonstar]

It looks like this is already the case in 0.4.x. Should it still return a Cursor<BytesMut>? Or should BytesMut implement Buf directly instead?

[carllerche]

BytesMut should impl Buf directly. Maybe it does already? Either way, it has the capability to do so.

[YetAnotherMinion]

I ran into problems with impl Buf for BytesMut. Specifically when removing advance from BytesMut and using the Buf's impl reveals that there are conflicting take methods on Buf and BytesMut.

BytesMut::take takes everything and passes ownership into a new BytesBuf, while Buf::take allows configuring how much is taken, but during the transferring ownership instead portion of its act, it consumes self, basically acting like truncate (without changing the underlying storage).

Can someone here give me more background information about the use case for the two different functions? I do not think the functionality of the two can be merged because they are doing fundamentally different things with ownership.

The simplest solution I can think of is just renaming the functions. I think that BytesMut::take should keep the name, and Buf::take should be renamed to something like Buf::prefix (and Take to Prefix).

[mzabaluev]

I, too, was confused with the disparate take methods. But my solution for this would be to replace BytesMut::take with a trait API that would work on both Bytes and BytesMut (and their UTF-8 counterparts StrChunk/StrChunkMut being incubated in that crate) and allow the user to specify a range to take. So received_bytes.take() would be received_bytes.take_range(..).

[mzabaluev]

So received_bytes.take() would be received_bytes.take_range(..).

I have now distilled that into crate range-split.