Add find_map to the Iterator trait

[Cobrand]

This is a very simple proposition to add a find_map trait method to the Iterator trait.
It would look like this :

fn find_map<B, P>(&mut self, predicate: P) -> Option<B> where P: FnMut(&Self::Item) -> Option<B>;

Currently to reproduce similar behavior, one would have to use a combination of filter_map and next. It is obvious for the Rust connoisseur that is aware that an Iterator is lazy and will not do anything unless consumed, but it much less obvious for the standard programmer that doesn't think this way yet.

Let's take an example :

#[derive(Debug,Copy,Clone)]
enum Flavor {
    Chocolate,
    Strawberry,
    Cherry
}

#[derive(Debug,Copy,Clone)]
enum Dessert {
    Banana,
    Pudding,
    Cake(Flavor)
}

fn main() {
    let desserts_of_the_week = vec![
        Dessert::Banana,
        Dessert::Cake(Flavor::Chocolate),
        Dessert::Pudding,
        Dessert::Pudding,
        Dessert::Pudding,
    ];
}

If I want to have the "flavor of the cake of the week", as an Option<Flavor>, a non-newbie Rust user will use this :

let cake_of_the_week : Option<Flavor> = desserts_of_the_week.iter().filter_map(|dessert|{
        match dessert {
            &Dessert::Cake(ref flavor) => Some(flavor.clone()),
            _ => None
        }
    }).next();

However a new user will be tempted to do something like this :

let cake_of_the_week : Option<Flavor> = desserts_of_the_week.iter().find(|dessert|{
        match dessert {
            &&Dessert::Cake(_) => true,
            _ => false
        }
    }).map(|dessert|{
        match dessert {
            &Dessert::Cake(ref flavor) => flavor.clone(),
            _ => unreachable!()
        }
    });

That is why I propose to add a find_map method to the Iterator trait, which would

• Reduce a little bit your code and increase readability (in the case of filter_map(...).next()
• Avoid new users to code in a non-idiomatic way

It would then look like this :

let cake_of_the_week : Option<Flavor> = desserts_of_the_week.iter().find_map(|dessert|{
        match dessert {
            &Dessert::Cake(ref flavor) => Some(flavor.clone()),
            _ => None
        }
    });

There aren't that much advantages, but I still do think it's worth the while to add such a method.

Maybe this has been discussed before, in that case I'd appreciate a link to some discussion related to this topic, because I could not find anything.

Thoughts ?

[bluss]

The closure should get the iterator element by value. In that shape find_map is a good generalization of find, all, any, position etc, so it is a candidate for being the basis method of all of those (similar to this draft plan, and similar to search_while here (internal method)).

[brendanzab]

@bluss Perhaps find_map could be trialed on your itertools crate in the meantime?

[bluss]

Sure. I'm also happy since it's a better alternative to the “search_while” alternative in the draft RFC.

[bluss]

cc @Veedrac

[Veedrac]

@bluss Lots of iterator methods are already technically equivalent in this sense; all can emulate find_map just as much as the other way around. find_map doesn't strike me as a better basis method; we probably want either simpler (all) or safer (fold_while).

In terms of adding find_map on its own merits, I don't have a strong opinion. It feels better suited to itertools, though.

[bluss]

Concretely I don't agree.

To implement find_map with all, you have to do some tricky closure capture logic that is not neat. The reverse is trivial.

The same goes for fold_while and all, except the closure capture logic is even worse.

[Veedrac]

Doesn't seem that tricky to me.

let mut ret = None;
iter.all(|x| { ret = predicate(x); !ret.is_some() });
ret

Anyway, in theory people will never have to build on top of an abstraction they don't like - that will be done once in the standard library. From then on the only time they will be required to use all directly is when they are overloading it, in which case the simpler to implement the better, or when it turns out to be the nicest way to express the logic they want.

Using fold_while as the primitive makes every it harder to create a new iterator with fast internal iteration, and only benefits the standard library.

[bluss]

Yes I agree with that, but using all to make a fold_while or fold is not as simple as that.

[Veedrac]

Oh, yeah I see what you mean for the ones with accumulators.

[bluss]

@Veedrac Do you want to collaborate on an RFC? I'd prefer either the fold_while, rfold_while (2 methods) or the find_map, rfind_map, fold, rfold (4 method) approaches, with the methods inside the iterator traits.

[Veedrac]

@bluss I'd be happy to help. The draft for fold_while looks pretty solid, and nicer than a 4-method approach. I still think Result is more ergonomic, so I'd push for calling that fold_ok to fix the semantic mismatch.

[bluss]

Discussion about that side track can continue on the internals forum Pre-RFC: fold_ok is composable internal iteration.

I'm sorry for the disruption @Cobrand!

[scottmcm]

The side track now exists as try_fold as of rust-lang/rust#45594, in case that can unblock this.

[matklad]

+1

I want this so often that I've even written a PR (rust-lang/rust#49098), and, in the process of writing it up, stumbled upon this issue :)

[Centril]

The PR was merged so I'm closing this.