feat: Implement AsyncBufReadExt::fill_buf #1687
Conversation
|
The fact that this simple future requires unsafety to munge lifetimes makes me think that the definition of AsyncBufRead needs to change. |
Probably it will be API like rust-lang/rfcs#1015? pub trait AsyncBufRead: AsyncRead {
/// Attempt to read from the inner reader, and append the data onto the end of
/// any currently buffered data.
fn poll_read_into_buf(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<io::Result<usize>>;
/// Get a read-only view into the buffered data.
///
/// NOTE: This method **will not** do an implicit read if the buffer is empty.
/// It will just return an empty slice.
fn get_buf(&self) -> &[u8];
fn consume(self: Pin<&mut Self>, amt: usize);
} |
|
Yeah, that's what I was thinking. |
Adds a future wrapper around `AsyncBufRead::poll_fill_buf`. It unfortunately has to use unsafe to forget a lifetime but I hope the comment explains why this is safe.
Implementing a future based `fill_buf` method proves impossible without unsafe on the current API. By altering it to separate the reading into a buffer and retrieving the buffer we avoid this while simultaneously getting a more expressive API. `poll_fill_buf` still exists as a default method implemented by calling these new required methods. BREAKING CHANGE Implementors of `AsyncBufRead` must implement `poll_read_into_buf` and `get_buf` instead of `poll_fill_buf`
|
I altered The only downside I can see is that |
|
Thanks for doing this! Since @seanmonstar submitted the referenced RFC, I have requested his review on this PR. |
|
I am closing this PR in favor of refactoring the |
Adds a future wrapper around
AsyncBufRead::poll_fill_bufso that it can be used without needing to poll manually. It unfortunately has to use unsafe to forget a lifetime but I hope the comment explains why this is safe.