-
Notifications
You must be signed in to change notification settings - Fork 341
from/into stream #125
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
from/into stream #125
Conversation
Okay, so interesting fact here: if we actually want to provide implementations for I won't add it as part of this patch, but it seems like something that we should enumerate if we land this, and probably would make for a good issue to onboard folks with! edit: we currently can't add the |
Noticed another thing:
This not only applies to Ideally we could also expose edit: also it's probably worth talking to boats about the trait requirements for async iteration. This will probably influence what we do here. |
I've gone ahead and also implemented use async_std::prelude::*;
use async_std::stream;
let s = stream::repeat(9u8).take(3);
let buf: Vec<u8> = s.collect().await;
assert_eq!(buf, vec![9; 3]); I couldn't figure out the right trait bounds using static futures, so I just did a box bound on it. It shows up as |
@stjepang could you push your changes from last Tuesday if you have time? |
@yoshuawuyts I have pushed the changes into |
a247530
to
7bf3933
Compare
I had restore all the |
7bf3933
to
37c13e9
Compare
37c13e9
to
bf98c1e
Compare
Also note from private chat: we should introduce this feature behind the "unstable" flag. |
145: Add Stream::poll_next r=stjepang a=stjepang Adding `poll_next` to the `Stream` trait will simplify #125. After a discussion with @yoshuawuyts and @withoutboats, we became confident that the `Stream` trait of the future will never solely rely on `async fn next()` and will always have to rely on `fn poll_next()`. This PR now makes our `Stream` trait implementable by end users. I also made a few adjustments around pinning to `all()` and `any()` combinators since they take a `&mut self`, which implies `Self: Unpin`. A rule of thumb is that if a method takes a `&mut self` and then pins `self`, we *have to* require `Self: Unpin`. Co-authored-by: Stjepan Glavina <stjepang@gmail.com>
bca314a
to
0148df7
Compare
0148df7
to
98927a7
Compare
Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> update examples Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> impl collect Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> compiles! Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> layout base for collect into vec Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> fmt Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> progress Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> compiles! Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> define failing test Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> cargo fmt Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> stuck again Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> fix trait bounds! Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> cargo fmt Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> hide dyn fut impl Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> dyn ret for vec Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> cargo fmt Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> collect docs Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> remove macro from vec::from_stream Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> shorten collect trait bound Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com> Remove some Unpin and Send bounds Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
Signed-off-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
All feedback implemented; talked about this and we're happy to try this out as "unstable" 🎉 bors r+ |
125: from/into stream r=yoshuawuyts a=yoshuawuyts This adds `Stream` counterparts to `FromIterator`, `IntoIterator` and `Iterator::collect`, allowing to use the same patterns that are common in streams. Thanks! ## Tasks - [x] `FromStream` - [x] `IntoStream` - [x] `Stream::collect` ## Screenshot  Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
Build succeeded
|
207: Added the ability to collect a stream of results r=yoshuawuyts a=sunjay As requested here: https://twitter.com/yoshuawuyts/status/1174026374316773377 The standard library has a very useful implementation of `FromIterator` that takes an iterator of `Result<T, E>` values and is able to produce a value of type `Result<Vec<T>, E>`. I asked for this in `async-std` and @yoshuawuyts recommended that I contribute the impl. It turns out that the implementation in the standard library is even more general than I initially thought. It allows any collection that implements `FromIterator` to be collected from an iterator of `Result<T, E>` values. That means that you can collect into `Result<Vec<T>, E>`, `Result<HashSet<T>, E>`, etc. I wanted to add a similarly generic impl for this crate so we can also support collecting into any collection that implements `FromStream`. The implementation for this is based heavily on [what exists in `std`](https://github.com/rust-lang/rust/blob/9150f844e2624eb013ec78ca08c1d416e6644026/src/libcore/result.rs#L1379-L1429). I made a new `result` module since that's where this impl is in `std`. I still wanted to maintain the conventions of this repo, so I copied the `vec` module that @yoshuawuyts created in #125. Much like in that PR, the new `result` module is private. There is a doctest in the documentation for `collect` that both teaches that this feature exists and tests that it works in some simple cases. ## Documentation Screenshot  Co-authored-by: Sunjay Varma <varma.sunjay@gmail.com>
This adds
Stream
counterparts toFromIterator
,IntoIterator
andIterator::collect
, allowing to use the same patterns that are common in streams. Thanks!Tasks
FromStream
IntoStream
Stream::collect
Screenshot