-
Notifications
You must be signed in to change notification settings - Fork 341
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
from/into stream #125
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 <[email protected]>
bca314a
to
0148df7
Compare
0148df7
to
98927a7
Compare
Signed-off-by: Yoshua Wuyts <[email protected]> update examples Signed-off-by: Yoshua Wuyts <[email protected]> impl collect Signed-off-by: Yoshua Wuyts <[email protected]> compiles! Signed-off-by: Yoshua Wuyts <[email protected]> layout base for collect into vec Signed-off-by: Yoshua Wuyts <[email protected]> fmt Signed-off-by: Yoshua Wuyts <[email protected]> progress Signed-off-by: Yoshua Wuyts <[email protected]> compiles! Signed-off-by: Yoshua Wuyts <[email protected]> define failing test Signed-off-by: Yoshua Wuyts <[email protected]> cargo fmt Signed-off-by: Yoshua Wuyts <[email protected]> stuck again Signed-off-by: Yoshua Wuyts <[email protected]> fix trait bounds! Signed-off-by: Yoshua Wuyts <[email protected]> cargo fmt Signed-off-by: Yoshua Wuyts <[email protected]> hide dyn fut impl Signed-off-by: Yoshua Wuyts <[email protected]> dyn ret for vec Signed-off-by: Yoshua Wuyts <[email protected]> cargo fmt Signed-off-by: Yoshua Wuyts <[email protected]> collect docs Signed-off-by: Yoshua Wuyts <[email protected]> remove macro from vec::from_stream Signed-off-by: Yoshua Wuyts <[email protected]> shorten collect trait bound Signed-off-by: Yoshua Wuyts <[email protected]> Remove some Unpin and Send bounds Signed-off-by: Yoshua Wuyts <[email protected]>
Signed-off-by: Yoshua Wuyts <[email protected]>
Signed-off-by: Yoshua Wuyts <[email protected]>
Signed-off-by: Yoshua Wuyts <[email protected]>
Signed-off-by: Yoshua Wuyts <[email protected]>
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 <[email protected]>
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 <[email protected]>
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