Add try_map_results method.

[pthariensflame]

This method is like the existing map_results, but allows the provided closure to potentially fail with an Err value of its own on each input. The Err values from both the original iterator and the closure will show up in the output of the adaptor.

I felt the need for this method very recently in my own code; it's implementable manually in terms of Itertools::map_results, Iterator::map, and Result::and_then, but it's both cleaner and more obviously efficient if it's its own method.

[pthariensflame]

@bluss This is ready for review, whenever you have time.

[bluss]

@pthariensflame sorry for taking forever. Can we check if this is something that Rust's std wants to take?

[pthariensflame]

I suppose. I was assuming they wouldn't, since the map_results method this ”extends” is in itertools rather than std. Is there a particular procedure for checking?

[bluss]

@pthariensflame Either opening a PR there or checking interest with people in the libs team. Though I see your point, this seems to fit better in here. No chance some kind of try_map would do well in std?

In std with the try_ prefix, should it really be short circuiting like try_fold and try_for_each are?

[bluss]

cc @Centril :) what do you think?

[Centril]

@bluss Hmm; this seems to me a shorthand for iter.map(|x| x.and_then(closure)) so idk; it might be a nice ergonomics thing... I think if it makes sense for itertools it makes sense for libcore; conversely, if it doesn't make sense for libcore it probably doesn't make sense for itertools.

[jswrenn]

Sorry for the wait. Generally, I think we should stick with the core::Iterator convention that try_ is reserved for short-circuiting adaptors. I'm not opposed to ergonomic shortcuts, but this needs a more suitable name.

[pthariensflame]

@jswrenn Maybe map_and_then?

[jswrenn]

@pthariensflame map_and_then sounds good to me!

[pthariensflame]

@jswrenn How's it look now?

[phimuemue]

I have nothing against extending our map-convenience-function zoo, but I think we should first simplify our existing map_-variants (see #464) and express map_and_then in terms of a general map-convenience function. (Because we already have two map_-convenience adaptors that diverged in implementation, and I think we should avoid that.)

@pthariensflame I am sorry that this issue came to my mind so late. Would you also be ok with incorporating your idea once/if #464 becomes accepted?

[pthariensflame]

@philmuemue I’d be more than happy to!