search

rust-itertools / itertools

Extra iterator adaptors, iterator methods, free functions, and macros.
https://docs.rs/itertools/
Apache License 2.0
2.76k stars 309 forks source link

Do we need a `rfind_map`? #949

Closed Xenira closed 6 months ago

Xenira commented 6 months ago

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 commented 6 months ago

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 https://github.com/rust-itertools/itertools/pull/818#discussion_r1425902068 where we had the same thought.

Is it really missing though?

Xenira commented 6 months ago

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 commented 6 months ago

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: https://github.com/rust-lang/libs-team/issues/385

Xenira commented 6 months ago

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 commented 6 months ago

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.