Please consider integrating fallible iterator adaptos from iterator-ext

[jerry73204]

I made a series of try_{filter_map,flat_map, ...} adaptors in my iterator-ext. I wish itertools can have them. Not sure if this feature was proposed or worked out before. If yes, I'm glad to know the reasons.

I acknowledge the relevant fallible-iterator crate. It needs an explicit conversion from standard iterator to fallible iterator. I would flavor the itertools approach to work as drop-in solution.

[jswrenn]

Also relevant for consideration: https://blog.yoshuawuyts.com/fallible-iterator-adapters

[scottmcm]

It needs an explicit conversion from standard iterator to fallible iterator. I would flavor the itertools approach to work as drop-in solution.

The other potential view here is that it's better to switch into that mode, so that the normal method names do the normal things, rather needing to say try_ on all of them.

Relatedly, it also makes it much easier to read the docs if there's one trait with the normal value methods, and a different trait for the Result value methods.

[jerry73204]

The other potential view here is that it's better to switch into that mode, so that the normal method names do the normal things, rather needing to say try_ on all of them.

If the fallible iterator is explicit, it's better to be transparent to normal Iterator. We can pass the fallible iterator to an argument accepting impl IntoIterator<Item = XXX> or whatever. Or we can make the conversion as easy as .into_std_iterator().

Relatedly, it also makes it much easier to read the docs if there's one trait with the normal value methods, and a different trait for the Result value methods.

That's the way futures crate has StreamExt and TryStreamExt.