-
Notifications
You must be signed in to change notification settings - Fork 288
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
Buf::copy_to_bytes #129
Comments
I'd like this too. There's |
The initial idea was to have `decode()` take a `Buf` and `encode()` take a `ButMut`, as they semantically should. It would have enabled our users to use other buffer backends. Switching `encode()` to take a BufMut was straightforward, that's done. Concerning `decode()`, `Buf` currently lacks facilities to rewind the read position (tokio-rs/bytes#330) and to read a specified number of bytes (tokio-rs/bytes#129), making it impossible to implement the desired API unless we assume that our user is using a continuous-memory backend like BytesMut (and even then, the implementation isn't really pretty). It is possible to have `decode()` take a `Bytes` (as it semantically should) instead of a `BytesMut`, but because users typically want to pass a `BytesMut` to `TcpStrem.read()` it would require a `.freeze()` before passing to `decode()`, which is cumbersome and prevents buffer reuse. With all that said, this commit does move things in the right direction, and if upstream fixes the mentioned bugs it'll be that much easyer to switch.
The initial idea was to have `decode()` take a `Buf` and `encode()` take a `ButMut`, as they semantically should. It would have enabled our users to use other buffer backends. Switching `encode()` to take a BufMut was straightforward, that's done. Concerning `decode()`, `Buf` currently lacks facilities to rewind the read position (tokio-rs/bytes#330) and to read a specified number of bytes (tokio-rs/bytes#129), making it impossible to implement the desired API unless we assume that our user is using a continuous-memory backend like BytesMut (and even then, the implementation isn't really pretty). It is possible to have `decode()` take a `Bytes` (as it semantically should) instead of a `BytesMut`, but because users typically want to pass a `BytesMut` to `TcpStrem.read()` it would require a `.freeze()` before passing to `decode()`, which is cumbersome and prevents buffer reuse. With all that said, this commit does move things in the right direction, and if upstream fixes the mentioned bugs it'll be that much easyer to switch.
The initial idea was to have `decode()` take a `Buf` and `encode()` take a `ButMut`, as they semantically should. It would have enabled our users to use other buffer backends. Switching `encode()` to take a BufMut was straightforward, that's done. This solves a gotcha about using `bytes::BytesMut` vs `bytes::bytes_mut::BytesMut`, and enables the use of other buffer types, like `Vec`. Concerning `decode()`, `Buf` currently lacks facilities to rewind the read position (tokio-rs/bytes#330) and to read a specified number of bytes (tokio-rs/bytes#129), making it impossible to implement the desired API unless we assume that our user is using a continuous-memory backend like BytesMut (and even then, the implementation isn't really pretty). It is possible to have `decode()` take a `Bytes` (as it semantically should) instead of a `BytesMut`, but because users typically want to pass a `BytesMut` to `TcpStrem.read()` it would require a `.freeze()` before passing to `decode()`, which is cumbersome and prevents buffer reuse. With all that said, this commit does move things in the right direction, and if upstream fixes the mentioned bugs it'll be that much easyer to switch.
Bikeshedding: Maybe |
Buf
could havecopy_to_bytes
operation:Default implementation should simply allocate new
Bytes
, while implementation forBytes
could callslice
.The text was updated successfully, but these errors were encountered: