Tracking issue for Iterator::try_fold and try_rfold (feature iterator_try_fold)

[scottmcm]

The core internal iteration methods in terms of which the other Iterator methods can be implemented.

PR #45595, commit b32267f -- merged 2017-11-17
https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.try_fold
https://doc.rust-lang.org/nightly/std/iter/trait.DoubleEndedIterator.html#method.try_rfold

Also try_for_each (PR #48157, merged 2018-02-24), a convenience method that can be considered the fallible version of for_each or the stateless version of try_fold.
https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.try_for_each

Pre-stabilization question list:

• Are these the best type parameters? Inference worse in method signature using associated type than with new generic type parameter eq-constrained to the associated type #45462
• Should there be a try_foreach as well? impl FromIterator<()> for () #45379 (comment)
• Stabilize rfold before try_rfold? Tracking issue for Iterator::try_fold and try_rfold (feature iterator_try_fold) #45594 (comment)
• Stabilize try_fold before the others? Tracking issue for Iterator::try_fold and try_rfold (feature iterator_try_fold) #45594 (comment)

[leonardo-m]

Is this usable to implement a fold1?

http://zvon.org/other/haskell/Outputprelude/foldl1_f.html

[bluss]

There's already a fold1 in itertools and its implementation is quite simple:

    fn fold1<F>(mut self, f: F) -> Option<Self::Item>
        where F: FnMut(Self::Item, Self::Item) -> Self::Item,
              Self: Sized,
    {
        self.next().map(move |x| self.fold(x, f))
    }

The major difference to haskell foldl1 is that itertools fold1 returns an Option, with None for when the iterator is empty, instead of a runtime error like in Haskell.

[scottmcm]

That same technique is also used for the min & max methods on Iterator: https://github.com/rust-lang/rust/pull/45595/files#diff-1398f322bc563592215b583e9b0ba936R2360

[cuviper]

I think try_rfold should conceptually depend on stabilizing rfold first -- #44705.
(even though the default implementation goes the other way, rfold calling try_rfold)

[scottmcm]

Well, rfold is already in the current beta, so it could probably be proposed for stabilization in 1.23...

[cramertj]

I wound up writing some code that really wanted try_filter_map (return a Result<Option<T>> instead of just Option<T>), and instead wound up doing something like .map(|x| x.to_res_opt()).try_filter_map(res_opt_to_opt_res). I wound up opening this PR as a result, which allows you to use Into to get the res_opt_to_opt_res behavior, however I still think built-in try_xxxs are more straightforward (I could see try_filter, try_filter_map, try_scan, try_inspect, etc... all being handy). I'm not sure how far we should take this before we just say to write a dang for loop 😜

[cuviper]

Should we try to stabilize try_fold alone? (leaving try_rfold and try_for_each for later)

[SoniEx2]

Why not try_fold into Iterator<R>? make it the opposite of flat_map!