Skip to content
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

Add stream::from_iter #400

Closed
yoshuawuyts opened this issue Oct 28, 2019 · 4 comments · Fixed by #415

Comments

@yoshuawuyts
Copy link
Member

@yoshuawuyts yoshuawuyts commented Oct 28, 2019

It's quite common to want to create a stream from an iterator. Currently we're having a lot of VecDequeue in our examples because it implements Stream, but that might not stay around (see rust-lang-nursery/futures-rs#1879).

So I propose we add a new function stream::from_iter that returns a struct FromIter, similar to how we have stream::from_fn that returns FromFn.

This is mostly as a pragmatic fix for the fact that we can't implement IntoStream for std types ourselves (see #129), and probably in general useful when porting codebases. The value of this function should decrease if we can resolve that, but in order to do so the VecDequeue must be removed first, so in order to break the somewhat recursive dependency there I propose we add this function.

Because we'd want to use this function to replace all uses of VecDequeue we currently have in our examples, and we're in somewhat of time pressure (futures@0.3.0 is in 9 days), I'd like to propose we make an exception here and introduce this without the "unstable" marker.

edit: unsure about stability. More in follow-up comment.

cc/ @stjepang

Examples

let nums = stream::from_iter(vec![0, 1, 2, 3, 4]);

while let Some(num) = nums.next().await {
    dbg!(num);
}
@yoshuawuyts

This comment has been minimized.

Copy link
Member Author

@yoshuawuyts yoshuawuyts commented Oct 28, 2019

Riffing on this more: actually the preferred outcome would be to have

impl<I: Iterator> IntoStream for I

We currently can't do this, but such a bound seems like it'd be ideal. That way any Iterator impl could be converted to a stream, yet into_iter and into_stream methods could co-exist on any given type. This would also remove the need for stream::from_iter, which admittedly isn't quite what we want.

Actually I'm wondering if instead of instant-stabilizing stream::from_iter we can introduce this as "unstable" for doc purposes. We could then punt stabilizing this (or removing it entirely) for later. Or perhaps we stabilize it and revisit this for any possible 2.0 release. Unsure, but would be keen to hear thoughts. Thanks!

@yoshuawuyts

This comment has been minimized.

Copy link
Member Author

@yoshuawuyts yoshuawuyts commented Oct 29, 2019

Going to go ahead and mark this "good first issue". It should be fairly straight forward to implement stream::from_iter. Thanks!

@k-nasa

This comment has been minimized.

Copy link
Member

@k-nasa k-nasa commented Oct 29, 2019

Can I try this

@yoshuawuyts

This comment has been minimized.

Copy link
Member Author

@yoshuawuyts yoshuawuyts commented Oct 29, 2019

@k-nasa go for it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.