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.
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.
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).
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.
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.