Thoughts on moving (parts of) itertools to std?

Occasionally I need to do a small thing with an iterator that is supported by itertools but not by std. E.g. today I wanted to unpack an iterator into a tuple. Pulling in itertools just for one function seems heavy. I guess others may have similar experience.

Was there any discussion about moving itertools or its part into std? Are there good arguments against it? From quick search I didn't find anything.

I believe this would be a great way to make Rust feel a bit more batteries-included without actually bloating std too much.

It happens occasionally on a method by method basis. For example, itertools had fold1 before reduce (nee fold_self) was implemented in std and stabilized.

For collection into tupple, see https://github.com/rust-lang/rust/pull/79659 and a bunch of linked PRs.

My TL;DR is that the design of the error type is a tricky bit.

Don't we still need a design on how to move an iterator method with the same name from itertools to std? If it's just transferred with the same name, existing users of that itertools method will have a compile error unfortunately.

Fortunately, many of the features can be renamed.

There is an alternative, which is that itertools puts those behind compile flags.

I'm not advocating one alternative over another btw. Just mentioning it as a theoretical possibility.

I'm worried about this scenario: Say libstd introduces an unstable Iterator::fold1. Since it's unstable, it can't be used in stable compile and it still conflicts with Itertools::fold1 (or have the resolution rules changed?).

If not for the unstable/stable issue, itertools could use autocfg and see if the required methods were reachable - and avoid most breakage that way (not all).

Wouldn't this RFC help?

This can't fix all the people using an old version of itertools, though.

Maybe if most people have moved to a new version of itertools that's cfg(accessible)'d all the methods.

No it wouldn't, but it would give them an easy upgrade path, by just adjusting the version as normal, then adding a feature flag (or possibly 1 per fn that should be added), and they're done.

1 Like

This doesn't work if an old version of itertools it's an indirect dependency

That could be tackled by patching itertools in their own project before the intermediate dependency (the one that directly depends on itertools) gets updated, conceptually much as you would now.

It is possible that that would require some additional support from Cargo though, to allow a developer to specify in their own project's Cargo.toml which features they want enabled in the patched dependency.

There is an open PR to add the dedup , dedup_by and dedup_by_key methods to std.