Tracking Issue for `VecDeque::truncate_to_range`

[cammeresi]

Feature gate: #![feature(vec_deque_truncate_to_range)]

This is a tracking issue for adding truncate_to_range to VecDeque.

This function can truncate both ends of a VecDeque, keeping only the specified range in the middle. This operation is O(1) if there is no Drop code.

metrics.truncate_to_range(start..end);
// is equivalent to
metrics.truncate(end);
metrics.truncate_front(metrics.len() - start);

Public API

impl<T, A: Allocator> VecDeque<T, A> {
    pub fn truncate_to_range<R>(&mut self, range: R)
    where
        R: RangeBounds<usize>;
}

Steps / History

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

• ACP: VecDeque::truncate_to_range libs-team#785
• Implementation: Implement VecDeque::truncate_to_range #156220
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Name. Should this be truncate_to_range, or retain_range?

Footnotes

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

[cuviper]

truncate and truncate_front silently ignore lengths that are greater than the current length. What are the requirements of the range here? The ACP only sketched a "validate range" step without details -- must it be in bounds? And must it have start <= end like slicing generally requires? If the validation is not a silent return, does that make it a panic condition?

[cammeresi]

The ACP only sketched a "validate range" step without details -- must it be in bounds? And must it have start <= end like slicing generally requires? If the validation is not a silent return, does that make it a panic condition?

Yes to all, at least subject to code review. The implementation patch I posted calls slice::range, so all of those things are checked, and the function will transitively panic.