Rust: Tracking issue for iterator_fold_self

[KodrAus]

Initial implementation: #65222

Tracking issue for Iterator::fold_first, like fold1 in Haskell.

Open questions

• [ ] Naming. Do we like fold_first?
• [ ] Should we reconsider try_fold_first?

Stabilisation checklist

• [ ] Docs
• [ ] Stabilisation PR

[turion]

For me as a Haskeller who relatively new to Rust, try_fold_first sounds right, because it returns an Option.

[pcpenpal]

Following Scala's approach, what about reduce?

[Danue1]

Kotlin is doing the same naming.

https://kotlinlang.org/docs/reference/collection-aggregate.html#fold-and-reduce

[Riey]

I prefer reduce because it quite different from fold

fold compute acc with all elements then return acc type

but reduce compute all elements into one then return element type

[Kroisse]

reduce might be conflict with ParallelIterator::reduce in Rayon, which has the identity parameter act as fold's init parameter.

[WaffleLapkin]

Why only Iterator::fold_first was implemented and not DoubleEndedIterator::rfold_first? Is it appropriate to make a PR that adds the later method?

[rossmacarthur]

I think reduce is an appropriate name for this function. try_fold_first would also be better than fold_first.

[jagill]

This functionality is very useful for situations where there's no reasonable default value. For example, I'm using it for a parser, and would be very interested in it being stabilized.

I don't have a strong opinion on the name.

[amrhassan]

I concur, this would be very useful regardless of the name.