Impl into_vec for Bytes

[avitex]

• Carries on from the work in PR Add conversion from Bytes to Vec #151
• Doesn't fully close issue Bytes[Mut]::into_vec() #86 as BytesMut::into_vec is not implemented. Currently you cannot
  convert from a BytesMut to a Vec from a public interface (as like Bytes does) so I left this out for the time being.
• I'm not 100% on the atomic guarantees here.

Side note, I've noticed there is a decent amount of repetition and other tid bits of work that can be done in this lib. Old comments referring to Inner etc, no use of cargo fmt. I'm happy to jam a decent amount of time into helping refactor, but I would first like to check no other work of this kind is being done offline so I'm not duplicating it. Would the maintainers be interested in PRs of this sort?

[avitex]

Any updates on a possible merge of this?

[seanmonstar]

I'm sorry I missed this the first time!

For this concept, my gut feeling is that adding into_vec to the vtable feels out of scope. It being there would require any new implementers (once we make the vtable public) to figure out how to convert back into a Vec. I suppose if there was simply a way to decompose the Bytes back into the ptr and vtable, then a user could (unsafely) make an into_vec themselves...

[avitex]

Had I known you were planning on making the vtable public, I may have have taken another approach. What if the function consumes into a box slice? Data returned in that matter will be on the heap so returning a boxed slice would make sense. Either that or returning raw parts internally (which on a clone would require first assembling to a box slice and back into raw parts to return). What would be your preference?

[seanmonstar]

What do you mean by consuming into a boxed slice? What does that look like?

[avitex]

Changing into_vec to into_boxed_slice, or if you want to break into raw parts (which wouldn't fully make sense to me), into_raw_parts.

It's VTable specific, so I'm not sure how you're going to get around not having it required if you want the optimization.

[avitex]

Friendly poke on this