Implement functionality like Iterator::try_fold
#495
Assignees
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 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Iterator::try_foldis currently unstable -- rust-lang/rust#45594.For
Iterator::fold, rayon hasfoldthat operates per-split, which you mustreduceto get down to one final accumulator. I expecttry_foldshould be similar.We should wait until it's stabilized in
stdbefore we add it to rayon, so we can mimic the final signature.The text was updated successfully, but these errors were encountered: