-
Notifications
You must be signed in to change notification settings - Fork 497
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
Implement functionality like Iterator::try_fold
#495
Labels
Comments
I already started this: https://github.com/cuviper/rayon/commits/try_fold |
4 tasks
bors bot
added a commit
that referenced
this issue
Jun 27, 2018
563: [WIP] Add try_fold, try_for_each, try_reduce r=nikomatsakis a=cuviper There are six variations here, matching the existing non-try suite: - `try_fold` and `try_fold_with` - `try_for_each` and `try_for_each_with` - `try_reduce` and `try_reduce_with` All of them operate on `Try::Ok` values similar to the exiting non-try methods, and short-circuit early to return any `Try::Error` value seen. This `Try` is a pub-in-private clone of the unstable `std::ops::Try`, implemented for `Option<T>` and `Result<T, E>`. TODO and open questions: - [ ] Needs documentation, examples, and tests. - [x] Should we wait for `Iterator::try_fold` and `try_for_each` to reach rust stable? They were stabilized in rust-lang/rust#49607, but there's always a chance this could get backed out. - **Resolved**: they're stable in 1.27 - [x] Should we wait for stable `std::ops::Try`? We could just keep ours private for now, and change to publicly use the standard trait later (on sufficiently new rustc). - **Resolved**: keep our pub-in-private `Try` for now. - [x] Should `try_fold` and `try_fold_with` continue to short-circuit globally, or change to only a local check? - When I first implemented `try_reduce_with`, I use a `try_fold` + `try_reduce` combination, like `reduce_with`'s implementation, but I didn't like the idea of having double `full: AtomicBool` flags in use. - If `try_fold` only errors locally, then other threads can continue folding normally, and you can decide what to do with the error when you further reduce/collect/etc. e.g. A following `try_reduce` will still short-circuit globally. - **Resolved**: changed to just a local check. Closes #495. Co-authored-by: Josh Stone <cuviper@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Iterator::try_fold
is currently unstable -- rust-lang/rust#45594.For
Iterator::fold
, rayon hasfold
that operates per-split, which you mustreduce
to get down to one final accumulator. I expecttry_fold
should be similar.We should wait until it's stabilized in
std
before we add it to rayon, so we can mimic the final signature.The text was updated successfully, but these errors were encountered: