Tracking Issue for iter::repeat_n() (feature(iter_repeat_n))

[scottmcm]

Feature gate: #![feature(iter_repeat_n)]

This is a tracking issue for the iter::repeat_n function and its associated iter::RepeatN type.

This is like repeat, but count-limited so it can re-use the buffer when generating the last item.

ACP rust-lang/libs-team#120 is still open, but I'm sending a PR for it anyway as part of fixing a bug in VecDeque.

Public API

// core::iter

fn repeat_n<T>(element: T, count: usize) -> RepeatN<T>;

pub struct RepeatN<T>(…);

impl<T: Clone> Iterator for RepeatN<T> { … }
impl<T: Clone> DoubleEndedIterator for RepeatN<T> { … }
impl<T: Clone> ExactSizeIterator for RepeatN<T> { … }
impl<T: Clone> FusedIterator for RepeatN<T> { … }
impl<T: Clone> TrustedLen for RepeatN<T> { … }

Steps / History

• Implementation as doc(hidden): VecDeque::resize should re-use the buffer in the passed-in element #104435
• ACP: ACP: Uplift iter::repeat_n from itertools libs-team#120
• Un-hidden: Un-hide iter::repeat_n #120045
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[Amanieu]

Even if we decide to accept #106943, having a simple and ergonomic way to repeat a value N times is still useful.

@rfcbot fcp merge

[rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[joshtriplett]

Is this still going to be blocked on item shadowing, to avoid breaking itertools?

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[scottmcm]

@joshtriplett No shadowing concerns for this because it's a function, not a trait method.

It'll only be an issue if you use itertools::*; use std::iter::*;, but that's self-inflicted.

[joshtriplett]

@scottmcm 🤦 Right, of course. Thank you.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[GnomedDev]

Did any discussion about using NonZero for repeat_n's argument go on? Would it be favorable to block stabilization until this mess is sorted out as from my look on the docs it hasn't reached stable yet?

[scottmcm]

Given that repeating zero times is a completely acceptable thing to do -- just like [x; 0] works -- I don't think there's any need to use NonZero<usize> for it. That's worth considering for things like .step_by(0) where it panics for zero, but when it works just fine with zero like here, I don't see any value in blocking zero. (After all, after let mut x = repeat_n(x, 1); x.next(); you have a zero-length repeat anyway.)