search

rust-itertools / itertools

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

Do we need a `rfind_map`? #949

Closed Xenira closed 1 month ago

Xenira commented 1 month 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 1 month 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 1 month 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 1 month 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 1 month 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 1 month 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.