Why `itertools` is not part of STD?

Article is interesting and explains some principles and guidelines behind composing STD.
I can understand why STD does not have rand or serde. That is obvious.
Comment of CAD97 explains why derive_more is not in STD. Because there are multiple ways to reach the same goal each of which has a tradeoff.

But all that does not explain why itertools::interleave is not part of STD. It's difficult to imagine multiple ways of implementing interleave or any tradeoff associated with it.

Note that Iterator is in core , where it doesn't even have access to an allocator. So Itertools gets extra possibilities just from that, like collect_vec .

I see. But std cant have multiple modules inside, multiple layers. Is having multiple layers in STD a drawback?

1 Like

Eight years ago Gankra tried to add it, but it was declined as being too esoteric. If you disagree with that judgement, please do open a new PR to add that feature (though you’ll have to address those concerns raised before).

As some examples of other things that have been moved into std originally from itertools: intersperse, fold1 (as reduce) and step (as step_by) — so it does happen, it just needs someone to drive forward the process.

So the answer to the question “Why is it not part of STD?” is “it is, but only the most desired and best-designed parts that people have taken the time to add”.


I don't have strong opinion.

Interesting to know. You are so long here.

There could possibly be some difference in what methods can be called how in different editions, but it must be possible to create an actual Iterator instance in one edition and use it as a parameter to a function declared in another edition. Likewiese for Box<dyn Iterator>, implying that the dynamic method tables must also be the same.


Currently there's only one version of std for all editions. Rust doesn't have ability to change std on per-edition basis (apart from special-case hacks like array's IntoIter). Even if editions could have multiple versions of the standard library, there's always an issue of language fragmentation and churn — people don't like having outdated books, tutorials, and updating their code even when it's technically doable.


The core answer is that itertools can make breaking changes, but std cannot.

That means that anything we add to Iterator we're stuck with in exactly that form forever. And since most of the provided things have no need to be overridden, there's no need to have them in core, so they might as well be in another crate if there's any question about it.

One common situation where that happens is things that might want lending iterators (formerly streaming iterators) in the future. For example, group_by says

This type implements IntoIterator (it is not an iterator itself), because the group iterators need to borrow from this value. It should be stored in a local variable or temporary and iterated.

So it's plausible that std doesn't want that right now, because it wants to leave the API space available for something that can be a (lending) iterator, once such a thing is possible.

Also, a bunch of the itertools things need extra types, not just the method on iterator. Things like MinMaxResult and EitherOrBoth are important for making some of them work, but it's not clear that core wants to have those.


There are pros and cons.. One point is exactly about me!

Discoverability for new users. People who are new to Rust are afraid of pulling in untrusted code, with good reason.

So. There is easy solution to reconcile all. Just public a small list of crates for beginners.
" Beginners!
Use following crates:

  1. Chrono - if you need data and time
  2. Rand - if you need random numeric
  3. Serde - . . .
  4. . . . - . . .
    . . ."
    In this forum, or in Cookbook, or in Crates.io.
    And it will keep the standard library small

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.