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.