This issue is about moving some Clippy lints into Rustc where they probably belong (but I suspect this issue will need to be split into several issues):
Similarly, I’d like in the stdlib some of the handy things currently in the Itertools crate (but there are some backwards compatibility problems in doing this, see what happened to the flatten() method):
https://crates.io/crates/itertools
But to me some of the things of itertools have a design problem that the Rust stdlib doesn’t have. (And I discuss this here instead of the Github page of itertools because I think some itertools things should be moved into the rust stdlib). An example of this problem is visible in the zip_longest method:
https://docs.rs/itertools/0.7.8/itertools/trait.Itertools.html#method.zip_longest
It’s similar to the function with the same name in the Python stdlib:
https://docs.python.org/3.0/library/itertools.html#itertools.zip_longest
(Note: the API of Python zip_longest has a problem, so here I am not saying that it’s better than the Rust version).
The Rust method yields EitherOrBoth structs:
https://docs.rs/itertools/0.7.8/itertools/enum.EitherOrBoth.html
In my opinion zip_longest is a useful method, but I think a standard library should reduce the infrastructure, reduce the number of things (and data structures) to remember. I understand that EitherOrBoth makes the API types of zip_longest more precise, but they add things to remember or to look into the documentation. So I think I’d like Rust zip_longest to return something that doesn’t need to define a new type like EitherOrBoth, something like:
(Option<T>, Option<T>)
In the Rust Itertools there are other similar examples of specialized return types that I think are similarly a problem, I think library functions should use standard types as much as possible:
https://docs.rs/itertools/0.7.8/itertools/enum.MinMaxResult.html