-
Notifications
You must be signed in to change notification settings - Fork 287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider replacing Bytes::make_mut by impl From<Bytes> for BytesMut #709
Comments
None of this mentions Note also that this |
…-rs#709) <Arc<T>>::make_mut returns a &mut T, such an API is doable for Bytes too and thus we should reserve Bytes::make_mut for that. Furthermore, it would be helpful to use From<Bytes> as a trait bound in some cases with other traits such as Hyper's body trait, where Hyper gives you Bytes values. Finally, making it impl From<Bytes> for BytesMut means the API is more easily discoverable as it appears on both Bytes and BytesMut.
Oh yes, I had forgotten that I wanted |
For the API you envision, following what |
This proposal seems reasonable to me. |
…#710) <Arc<T>>::make_mut returns a &mut T, such an API is doable for Bytes too and thus we should reserve Bytes::make_mut for that. Furthermore, it would be helpful to use From<Bytes> as a trait bound in some cases with other traits such as Hyper's body trait, where Hyper gives you Bytes values. Finally, making it impl From<Bytes> for BytesMut means the API is more easily discoverable as it appears on both Bytes and BytesMut.
Bytes::make_mut
is a very good addition to the API but I think it would be better if it was instead exposed as<BytesMut as From<Bytes>>::from
. Could this be done before the next bytes version is released?Bytes::make_mut
isn't released yet.The text was updated successfully, but these errors were encountered: