Rick Richardson

@HyeonuPark - This looks great. One concern I have is to ensure that 3rd party container implementors have everything they need to convert their containers to and from Bytes. Other...

Thinking more about `fn clone` in the impl... Maybe there should be a default implementation of clone, so that the implementor doesn't have to implement their own refcounting. Or maybe...

One more question: Should we specify that `from_bytes_parts` should panic if `refcount > 1`, or should it return a Result/Option?

For the AtomicPtr bits, we might need to re-export the relevant types from`loom::sync::atomic` or `core::sync::atomic` to be safe. ... and AtomicMut. I was able to make a working impl of...

> I really should have documented if more, that multiple Bytes cloned from the same Bytes doesn't share same instance T: BytesImpl. It's like if you have #[derive(Clone)] struct Wrapper(Arc);...

At a high level, we'd need a 4d matrix of functionality. These wouldn't necessarily all be separate buffer types, but we need to ensure that we can handle the use-cases....

I'm going to attempt a version that formalizes this lower-level API, and also uses more a Typestate scheme and enum based dispatch, which, among other things, is going to be...

> It wasn't intended to make generic SharedImpl a first class citizen. If we decide to make it, it would be a helper type on top of the BytesImpl API...

You mention the downcasting approach for `Bytes -> ByteMut` conversion. I guess we should try to implement that for `SharedImpl` and see how it works.

I made a PR with my proposed module and naming changes: https://github.com/HyeonuPark/bytes/pull/2 I will make an additional PR following that with some takes at implementing `try_resize` and `try_into_mut` to support...