-
Notifications
You must be signed in to change notification settings - Fork 632
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
impl IntoFuture for IntoIterator<IntoFuture>? #662
Comments
An interesting idea! I don't think this can be done, however, due to coherence :( |
I'm not sure what "coherence" means in this context. Can you direct me to a reference? |
Updated: Ilya directed me to |
Would an implementation for Vec or &[IntoFuture] work, then? |
As an alternative, might it be possible to allow for |
I looked into this, and was initially optimistic, because the following passes all of the tests:
...ie, But in practice, actually using
Part of the complexity of the inference would seem to stem from the fact that
...so it would seem that it could be simplified to:
In that case, the inference for Certainly a "major version bump" type change, but maybe interesting to explore? |
Mm... I guess my previous comment re-discovers #285. After re-implementing/applying #286, I was able to confirm that:
is inferred correctly. So perhaps once #286 lands this can be re-opened? I've found that using combinators is more legible than using static methods, as static methods require indentation rather than chaining. EDIT: Posted here for posterity: master...stuhood:stuhood/join-all-simplification |
@alexcrichton : Thanks! Worth re-titling and re-opening, or shall we open a new issue with regard to |
Makes sense to me to retitle, @nyarly do you agree that such an impl would solve your original use case? |
Honestly, I'm not sure. I'm looking at: // I'm eliding a bunch of "and_then" into a pretend url2future! macro
future::join_all(urls.iter().map(|url| url2future!(url)).collect::<Vec<_>>()) I'm not sure if urls.iter().map(|url| url2future!(url)).collect::<JoinAll<_>>() is preferable? If urls.iter().map(|url| url2future!(url)) Is there another benefit to |
@nyarly : If you're executing in a position that is expecting an
It's (more) explicit? Either an advantage or a disadvantage, depending. |
By analogy to the JoinN implementations, does it make sense for IntoIterator to be IntoFuture via join_all?
The text was updated successfully, but these errors were encountered: