Repository navigation
Tracking Issue for Iterator::intersperseย #79524
Description
This is a tracking issue for the Iterator::intersperse and intersperse_with methods. It is based on itertools::intersperse and is the iterator equivalent of Vec::join.
The feature gate for the issue is #![feature(iter_intersperse)].
Public API
// core::iter
pub trait Iterator {
fn intersperse(self, separator: Self::Item) -> Intersperse<Self>
where
Self: Sized,
Self::Item: Clone;
fn intersperse_with<G>(self, separator: G) -> IntersperseWith<Self, G>
where
Self: Sized,
G: FnMut() -> Self::Item;
}
#[derive(Debug, Clone)]
pub struct Intersperse<I: Iterator> where I::Item: Clone {}
impl<I> Iterator for Intersperse<I> where I: Iterator, I::Item: Clone {
type Item = I::Item;
}
pub struct IntersperseWith<I, G> where I: Iterator {}
impl<I, G> Debug for IntersperseWith<I, G> where I: Iterator + Debug, I::Item: Debug, G: Debug {}
impl<I, G> Clone for IntersperseWith<I, G> where I: Iterator + Clone, I::Item: Clone, G: Clone {}
impl<I, G> Iterator for IntersperseWith<I, G> where I: Iterator, G: FnMut() -> I::Item {
type Item = I::Item;
}Steps / History
- Implement
intersperse: AddIterator::intersperseย #79479 - Add
intersperse_with: Add Iterator::intersperse_withย #80567 - FCP
- Stabilization PR: Stabilize
Iterator::intersperse()ย #88548
(UPDATE: stabilization was reverted because there was a lot of breakage: Stabilizing Iterator::intersperse breaks a large number of cratesย #88967) - Determine how to avoid breakage and un-revert
- Add
impl<I: FusedIterator> FusedIterator for Intersperse<I>? (Can be added after stabilization, so not urgent.)
Unresolved Questions
None.
Activity
m-ou-se commentedon Jan 13, 2021
#80567 is adding
intersperse_withto this feature.Rollup merge of rust-lang#80567 - lukaslueg:intersperse_with, r=m-ou-se
Rollup merge of rust-lang#80567 - lukaslueg:intersperse_with, r=m-ou-se
Rollup merge of rust-lang#81173 - lukaslueg:intersperse_docs, r=m-ou-se
Rollup merge of rust-lang#82121 - lopopolo:pathbuf-osstring-extend, rโฆ
cyqsimon commentedon Mar 28, 2021
I would like to suggest a simpler, alternative name for this method -
weave. At the time of comment, the wordweaveis not yet used in Rust std.Intersperseis quite verbose (especially when compared toVec::join), but more importantly rarely used in common English.weaveis much more common and concise in comparison.ibraheemdev commentedon Mar 29, 2021
Scala and haskell both use
intersperse. Scalaz calls itintercalate.tmplt commentedon May 3, 2021
weaveis not on the list of terms I would search for when looking for the expected behavior. I'd even consider it vanity.A verbose function name describes its effect better. More so if the term is uncommon; there is then less ambiguity.
interspersedoes exactly what is says: intersperse elements with a common separator.arnabanimesh commentedon May 10, 2021
why not use
joinandjoin_withfor iterators too?fosskers commentedon May 18, 2021
intercalateis slightly different.redgoldlace commentedon Jun 20, 2021
I feel like
joinimplies the creation of something monolithic from a sequence and a separator, i.ewill create the string
foo bar blah, and I don't have any issue with that.But in my mind
interspersebetter communicates the idea of placing separators in between a sequence, without creating something monolithic using the results of that.I suppose I mean that if I intersperse an iterator of
&strs with" ", it makes sense to me that I get an iterator back.But if I have an iterator of
&strs, and the method is namedjoin, I feel like it's a little less clear. Without looking further into it, it might seem like that I'd get a concatenatedStringback, or similar.For other types it may be less unclear but I'm still unsure on whether calling the method
joinis a good fit.54 remaining items
kornelski commentedon Mar 26, 2024
It can't be
join, because that's already taken by a slightly different operation that also collects.Vec::join("")returns a single joinedString. So doesItertools::join.Both join functions call their argument a separator. Therefore I think
Iter::separate(_by) makes the most sense for the iterator operation that happens under the hood of join.camelid commentedon Mar 26, 2024
I see, that makes sense. It does seem like
Iter::separateorseparate_byare best then. Perhaps we dointersperse -> separateandintersperse_with -> separate_with?senekor commentedon Mar 26, 2024
My personal favorite would be
separate_withand nothing else. The version accepting a closure is more powerful and those couple characters won't hurt anybody. I look at it like this:The only purpose of having a
separateversion seems to me to save a couple (8) characters. Not worth it to clutter the standard library documentation in my opinion. But it doesn't matter that much either. Having both is fine too.lukaslueg commentedon Mar 26, 2024
@camelid I was arguing for not using
.join(), my bad.fn separate() -> Separateandfn separate_with() -> SeparateWithit is, then?workingjubilee commentedon Mar 27, 2024
I think
fn insert_betweenworks best, particularly if we only have the closure form, but I don't mindseparate_with. I agree that we only really need one form.camelid commentedon Mar 27, 2024
@workingjubilee my disagreement with wording like
insert_betweenis that it sounds very imperative, whereasIteratormethods (almost) always have declarative wording in line with their behavior.senekor commentedon Mar 27, 2024
I think
separate_withfits better thaninsert_betweenwith the grammatical pattern of existing iterator methods. Maybe other people turn the method names into sentences differently, but here's what my brain does:verb_adverbstep_bytake_whilecollect_intoseparate_withinsert_betweenlukaslueg commentedon Mar 27, 2024
I love a good bikeshedding just as everyone, yet before this Tracking Issue is overwhelmed with it, I suggest to wait and see on the merit of #79524 (comment) in it's own right. My guess is that the PR to simply evade blockers now being on I-libs-api-nominated will yield some insights on that.
jadebenn commentedon Apr 10, 2024
I just encountered a situation where this method would have been an excellent solution to a problem I was facing, but I was restricted to stable Rust and couldn't use another crate. It's a shame that it's been marked as unstable for so long given that it only seems to be blocked via a naming conflict with itertools.
Renaming seems like a reasonable solution to me, but I would also note that the corresponding depreciation request on the itertools github seemed to point to there not being a full understanding on their part that this was not being marked as stable because of the naming conflict. They wanted to wait for stability to deprecate their own method, leading to the current state of things.
farazshaikh commentedon Apr 28, 2024
better to have
intersperse(seprator, interval)where the marker needs to spaced everyiterval.Only problem i see is reconciling the meaning of iterval == 0. It could be
Examples:
[1,1,1,1].iter().intersperse(0,2) -> [1, 1, 0, 1,1, 0]Also would need a to capture the meaning for some output like
intersperse(??) -> [0, 1, 1, 0 , 1, 1]I specifically ran into this while looking for solution for KZG encoding that requrires a tranfroming a byte stream into 32 byte symbol with the first (big edian) byte to be zero.
https://docs.eigenlayer.xyz/eigenda/rollup-guides/blob-encoding
As it stands , this API looks like a "alternate" implementation of zip() with infinite iterator over the second iterator.
farazshaikh commentedon Apr 28, 2024
:( looks like a direct transation of this
https://hackage.haskell.org/package/base-4.19.1.0/docs/Data-List.html#v:intersperse
Would be gereat to know how to solve this usecase
[elt elt elt sep elt elt elt sep][sep elt elt elt sep elt elt elt]Amanieu commentedon Apr 29, 2024
To give an update, we're currently trying to work around the naming conflict with a language-level feature: #89151 (comment)
bew commentedon Sep 7, 2024
Will there be a way to access the current separator index when using
intersperse_with?