Tracking issue for iterator_fold_self

[KodrAus]

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

Steps

• Initial implementation: Proposal: fold_self and try_fold_self for Iterators #65222
• Stabilisation PR: Rename Iterator::fold_first to reduce and stabilize it #79805

Open questions

• Naming.
• fold_first
• fold_with_first
• fold1
• reduce
• ...
• Should we reconsider try_fold_first?

[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. fold_with_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.