Tracking Issue for new VecDeque methods prepend, extend_front, splice, extend_from_within and prepend_from_within (original) (raw)

Feature gate: #![feature(deque_extend_front)]

This is a tracking issue for 5 new methods on VecDeque similar to ones already on Vec or their counterparts that push to the front instead of back.

ACP: rust-lang/libs-team#658

Public API

// alloc::collections::vec_deque

impl VecDeque { // Preserves order of elements. pub fn prepend(&mut self, other: I) where I: IntoIterator<Item = T>, I::Iter: DoubleEndedIterator { self.extend_front(other.into_iter().rev()) }

// Reverses order of elements.
pub fn extend_front<I>(&mut self, other: I)
where
    I: IntoIterator<Item = T>;

pub fn splice<R, I>(&mut self, range: R, replace_with: I) -> Splice<'_, I::IntoIter, A>
where
    R: RangeBounds<usize>,
    I: IntoIterator<Item = T>;

}

impl<T: Clone> VecDeque { pub fn extend_from_within(&mut self, src: R) where R: RangeBounds;

// Preserves order of elements.
pub fn prepend_from_within<R>(&mut self, src: R)
where
    R: RangeBounds<usize>;

}

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• Implementation:
  • extend_front, prepend: add extend_front to VecDeque with specialization like extend #146861
  • extend_from_within, prepend_from_within: implement VecDeque extend_from_within and prepend_from_within #147161
  • splice: add VecDeque::splice #147247
• Final comment period (FCP)1
• Stabilization PR

Unresolved Questions

• Exact moving/allocation behavior of VecDeque::splice in the less optimal conditions (see "This is optimal if:" in the doc), see https://github.com/rust-lang/rust/pull/147247/files#r2507005344

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