Implementation of Buf for VecDeque

[vorner]

Since it can be easily re-filled.

I'll think about how (if possible) to implement BufMut too.

Related to #248.

[vorner]

Ah, I haven't read the comment on #248 yet… ok.

[carllerche]

The primary reason I am not a huge fan of implementing Buf and BufMut for VecDeque<u8> is that it feels weird to me that bytes() and bytes_mut() return different ranges. This is also why RingBuf used to have reader() and writer() accessors.

[carllerche]

BTW, if you release a crate, I'd be happy to include a section in the README that links to additional implementations of Buf / BufMut.

[vorner]

Isn't the different ranges somewhat a problem of Vec<u8> too? Well, the IntoBuf wraps it into a Cursor, but still.

Hmm, it seems it isn't reasonably possible to implement BytesMut for VecDeque anyway ‒ it doesn't expose a way to access the unused part of allocation or raw pointers inside it.

I'll keep the offer with readme in mind, but considering the above, I'll have to think if I even want to create the crate. It might still work in the use case I described, though, even without that ability.

[carllerche]

You are probably right about the inconsistency. I guess the question should be if it is reasonable for single types to impl both Buf and BufMut such that data is read from the front and written to the back.

[carllerche]

Cc @seanmonstar

[carllerche]

@vorner I'll re-open. I think you are probably right.

[carllerche]

@vorner Ok, this looks good. Do you want to add a BufMut impl or do you want it merged as is?

[vorner]

Probably as it is. As I said, I don't see a way to implement BufMut right now. If I come up with one later on, I'll open another PR.

Anyway, if this is becomes a problem or too much work when going to the 0.5, it's always possible to drop the support or you can ask me to port it. I'm not really a good maintainer of stuff, but I should at least be able to take care of what I wrote.