Do we need a rfind_map?

[Xenira]

While implementing DoubleEndedIterator for FilterMapOk i stumbled over the find_map in the Iterator's next implementation.
The most straight forward way to implement next_back would be to just inverse that, but rfind_back does not exist.

Would that be something itertools could need?

[Philippe-Cholet]

I think the std lib dismissed the idea, probably not more efficient than the alternative. I don't know where to find the info though.

The only thing related I have is #818 (comment) where we had the same thought.

Is it really missing though?

[Xenira]

Just struck me as odd, that there is find_map and no rfind_map. But guess rev() works fine as well and keeps the trait concise.

[scottmcm]

I've never sure where to stop for adding the reverse versions of things. Like rall and rany feel clearly superfluous, yet rposition is worth it because it's not just .rev().position.

This started me thinking "well why don't you want to write .rev().find_map?", where my guess is that the biggest reason is that rev takes self. So here's a stab at asking libs-api to let you write .as_rev().find_map instead, which would hopefully lessen the need to add more r versions of things: rust-lang/libs-team#385

[Xenira]

Well, maybe a bit constructed, but rall and rany could make sense if you know elements are not evenly distributed and the iterator may short circuit earlier :P

[scottmcm]

Yeah, not saying that you'd never want to run them backwards, just that they seems unusual enough to not need a dedicated method on DoubleEndedIterator.