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? #45462
• Should there be a try_foreach as well? #45379 (comment)
• Stabilize rfold before try_rfold? #45594 (comment)
• Stabilize try_fold before the others? #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!

[SimonSapin]

Are these the best type parameters? #45462

In a perfect world the two signatures would be equivalent, but the code that landed already uses the formulation that works better with inference so I think it’s better to keep it that way.

Stabilize rfold before try_rfold?
Stabilize try_fold before the others?

Let’s stabilize them all together? :)

@rfcbot fcp merge

As of today try_for_each has only been in Nightly for 21 days, but at the soonest it will reach the Stable channel in 1.26 on May 11 after almost three months. More likely in 1.27 after over 4 months.

[scottmcm]

@SimonSapin Looks like the rfcbot command didn't take. Does it need to be the first line?

[cramertj]

@scottmcm The issue was missing a team tag :). @SimonSapin If you try again it should enter FCP (I cannot, as I am not on the libs team).

[SimonSapin]

Let’s try again:

@rfcbot fcp merge

[rfcbot]

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

• @Kimundi
• @SimonSapin
• @alexcrichton
• @aturon
• @dtolnay
• @sfackler
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[ExpHP]

To be clear, this is stabilizing before the Try trait?

This completely slipped by me even though I desperately wish for it all the time, as I never would've figured that functions involving Try would be receiving stabilization yet. I hope we've gained enough experience using these to validate their utility?

---

Note: I know this is not unheard of; consider the Sum trait. However, Sum was a hack to get one very small (but important) function working. These functions, on the other hand, could see pretty wide use all over a codebase, and they set precedents for best practices involving Try. Best make sure they're up to snuff!

[scottmcm]

Yes, this is stabilizing before the Try trait.

That doesn't scare me on the flexibility side because, no matter how the Try trait changes, they have the same needs as ? and catch: get the value with which to continue, and turn that back into the fallible type.

On the consumption side, I'm not worried because this is basically the same as itertools's fold_results and fold_options merged into one via the trait, since those are the only two types that can actually be used with it for now anyway. (And it's also fold_while once you can make the type to make it nicer on stable.)

They've also been discussed for a while as core internal iteration methods, though those wins are only available to stdlib types until the Try trait stabilizes too.

Now, one could argue that try_for_each isn't really needed, but that was the case for for_each as well for a long time, so I think just having it is fine.

[rfcbot]

The final comment period is now complete.