Refactor try_find a little

[cuviper]

This works like find_map, but mapping to a Try type. It stops when Ok is Some(value), with an additional short-circuit on Try::Error. This is similar to the unstable try_find, but has the advantage of being able to directly return the user's R: Try type directly, rather than converting to Result.
(removed -- try_find_map was declined in review)

This PR also refactors try_find a little to match style. The E type parameter was unnecessary, so it's now removed. The folding closure now has reduced parametricity on just T = Self::Item, rather
than the whole Self iterator type. There's otherwise no functional change in this.

[rust-highfive]

r? @kennytm

(rust_highfive has picked a reviewer for you, use r? to override)

[leonardo-m]

Instead of Iterator::try_find_map I'd like more useful methods like Iterator::sorted, Iterator::unfold, and few other handy things.
I also propose to put to votes further additions to Iterator in the discussion groups instead, so more broadly useful things could be addd.

[cuviper]

@leonardo-m - the usual playground for such stuff is the itertools crate, which does actually have sorted and unfold. But try_find_map can't be implemented externally while Try is unstable.

[leonardo-m]

Why is try_find_map necessary? Why can't try_find_map wait Try to be stable so you can implment it in the playground itertools?

[cuviper]

It's on par with try_find, at least, and I think the API is even nicer since it doesn't force Result.

[kennytm]

This is non-trivial enough that I'm going to reassign it to an actual T-libs member 🙂.

r? @sfackler

[Dylan-DPC-zz]

r? @dtolnay

[dtolnay]

I think I would prefer not to add the new method. The other try iterator methods (try_fold and try_for_each) expose a tangible new capability over the non-try (fold, for_each) because the non-try do not have an ability to early terminate. But Iterator::find_map is already entirely about early termination. In find_map the closure is supposed to return Some if you want to early terminate and None to keep iterating, and find_map's return value gives the thing you early terminated with if any, whether that's an error or an object if you want. The proposed try_find_map is the same but with a "transposed" interpretation of the closure:

iter.try_find_map(|s| parse_even(s))

// equivalent to:
iter.find_map(|s| parse_even(s).transpose()).transpose()

All in all I don't think the benefit is there more than e.g. try_map, try_filter, try_filter_map, try_skip_while, try_scan, try_any, try_partition etc, and I'm not on board with more in this direction just for small convenience. I think the fallible-iterator crate is a suitable place for this kind of thing.

I would be happy to take the try_find fixes though: the doc fix, removed type parameter, and reduced parametricity.

[cuviper]

OK, thanks for the detailed consideration. I've dropped the try_find_map commit, so now this has just the try_find adjustments.

[dtolnay]

@bors r+

[bors]

📌 Commit db0d70e has been approved by dtolnay