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.
Iterator is in
core , where it doesn't even have access to an allocator. So
Itertools gets extra possibilities just from that, like
I see. But
std cant have multiple modules inside, multiple layers. Is having multiple layers in STD a drawback?
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
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
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,
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
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.
Use following crates:
- Chrono - if you need data and time
- Rand - if you need random numeric
- Serde - . . .
- . . . - . . .
. . ."
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.