add extend_front to VecDeque with specialization like extend #146861

antonilol · 2025-09-21T20:07:11Z

ACP: rust-lang/libs-team#658
Tracking issue: #146975

Text below was written before opening the ACP

Feature was requested in #69939, I recently also needed it so decided to implement it as my first contribution to the Rust standard library. I plan on doing more but wanted to start with a small change.

Some questions I had (both on implementation and design) with answers:

Q: extend allows iterators that yield &T where T is Clone, should extend_front do too?
A: No, users can use copied and/or cloned.
Q: Does this need a whole new trait like Extend or only a method on VecDeque?
A: No, see ACP.
Q: How do I deal with all the code duplication? Most code is similar to that of extend, maybe there is a nice way to factor out the code around push_unchecked/push_front_unchecked.
Will come back to this later.
Q: Why are certain things behind feature gates, cfg(not(test)) like vec::IntoIter here and cfg(not(no_global_oom_handling)) like Vec::extend_from_within? (I am also looking at implementing VecDeque::extend_from_within)
A: See add extend_front to VecDeque with specialization like extend #146861 (review)
Q: Should extend_front act like repeated pushes to the front of the queue? This reverses the order of the elements. Doing it different might incur an extra move if the iterator length is not known up front (where do you start placing elements in the buffer?).
A: extend_front acts like repeated pushes, prepend preserves the element order, see ACP or tracking issue.

workingjubilee · 2025-09-21T20:37:35Z

cc @the8472 a bunch of questions re: specialization that I believe you may be able to address

the8472

Why are certain things behind feature gates, cfg(not(test))

This is due to tests living in the alloctest crate and some of the tests need access to implementation details so they're done with #[path] module imports there which means the originals need to be disabled.
See #136642

cfg(not(no_global_oom_handling)) like

This one is an unstable feature previously used by the linux kernel. IIRC a few other projects are using it too. It's supposed to remove all methods that abort on oom rather than returning an error from alloc's API surface.

Feature was requested in #69939

It's recommended to file an API change proposal to get some preliminary review of the proposed API from the team.

Considering that there are open questions how the API should look like I think it'd be best to have that discussion on an ACP thread so we can focus on the implementation details there.

View changes since this review

the8472 · 2025-09-21T21:11:38Z

library/alloc/src/collections/vec_deque/spec_extend.rs

+}
+
+#[cfg(not(test))]
+impl<T, A: Allocator> SpecExtendFront<T, Rev<vec::IntoIter<T>>> for VecDeque<T, A> {


This is a curious specialization. Is the expectation that people will frequently use Rev to prepend to a vecdeque?

Anyway, specializations should have dedicated tests since they're not covered by the regular ones.

This is a curious specialization. Is the expectation that people will frequently use Rev to prepend to a vecdeque?

This depends on the design of extend_front, if it will act like repeated push_front, specializing this can have significant performance improvements. This would be used when prepending elements from a Vec into a VecDeque, in original order, a bit like the requested VecDeque::prepend (#69939 (comment)).

prepend (see tracking issue) will use this, it calls self.extend_front(other.into_iter().rev())

the8472 · 2025-09-21T21:25:34Z

cc @the8472 a bunch of questions re: specialization that I believe you may be able to address

I don't think any of the questions are specific to specialization?

library/alloc/src/collections/vec_deque/spec_extend.rs

rustbot · 2025-09-30T20:36:32Z

r? @joboet

rustbot has assigned @joboet.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

joboet

I'm not sure who to ping about the specialisation issue. Apart from that, this seems fine!

View changes since this review

library/alloc/src/collections/vec_deque/spec_extend.rs

bors · 2025-11-01T11:46:24Z

☔ The latest upstream changes (presumably #148337) made this pull request unmergeable. Please resolve the merge conflicts.

rustbot · 2025-11-01T17:30:32Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

…rator

joboet · 2025-11-06T10:32:35Z

Thank you!
@bors r+

bors · 2025-11-06T10:32:37Z

📌 Commit 5b96677 has been approved by joboet

It is now in the queue for this repository.

…r=joboet add extend_front to VecDeque with specialization like extend ACP: rust-lang/libs-team#658 Tracking issue: rust-lang#146975 _Text below was written before opening the ACP_ Feature was requested in rust-lang#69939, I recently also needed it so decided to implement it as my first contribution to the Rust standard library. I plan on doing more but wanted to start with a small change. Some questions I had (both on implementation and design) with answers: - Q: `extend` allows iterators that yield `&T` where `T` is `Clone`, should extend_front do too? A: No, users can use [`copied`](https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.copied) and/or [`cloned`](https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.cloned). - Q: Does this need a whole new trait like Extend or only a method on `VecDeque`? A: No, see ACP. - Q: How do I deal with all the code duplication? Most code is similar to that of `extend`, maybe there is a nice way to factor out the code around `push_unchecked`/`push_front_unchecked`. Will come back to this later. - Q: Why are certain things behind feature gates, `cfg(not(test))` like `vec::IntoIter` here and `cfg(not(no_global_oom_handling))` like `Vec::extend_from_within`? (I am also looking at implementing `VecDeque::extend_from_within`) A: See rust-lang#146861 (review) - Q: Should `extend_front` act like repeated pushes to the front of the queue? This reverses the order of the elements. Doing it different might incur an extra move if the iterator length is not known up front (where do you start placing elements in the buffer?). A: `extend_front` acts like repeated pushes, `prepend` preserves the element order, see ACP or tracking issue.

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 21, 2025

workingjubilee added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. needs-acp This change is blocked on the author creating an ACP. labels Sep 21, 2025

This comment has been minimized.

Sign in to view

the8472 reviewed Sep 21, 2025

View reviewed changes

This comment has been minimized.

Sign in to view

antonilol mentioned this pull request Sep 22, 2025

ACP: Add extend_front, extend_from_within, extend_from_within_front, prepend and splice to VecDeque rust-lang/libs-team#658

Closed

antonilol force-pushed the vec_deque_extend_front branch from a0a54e3 to 6da1b60 Compare September 22, 2025 13:11

antonilol mentioned this pull request Sep 24, 2025

Tracking Issue for new VecDeque methods prepend, extend_front, splice, extend_from_within and prepend_from_within #146975

Open

6 tasks

antonilol commented Sep 28, 2025

View reviewed changes

library/alloc/src/collections/vec_deque/spec_extend.rs Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

antonilol force-pushed the vec_deque_extend_front branch 3 times, most recently from 5c9b311 to d4ae120 Compare September 30, 2025 20:36

antonilol marked this pull request as ready for review September 30, 2025 20:36

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 30, 2025

rustbot assigned joboet Sep 30, 2025

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Sep 30, 2025

antonilol changed the title ~~add extend_front to VecDeque with specialization like extend (unfinished)~~ add extend_front to VecDeque with specialization like extend Oct 12, 2025

joboet removed the needs-acp This change is blocked on the author creating an ACP. label Oct 21, 2025

joboet approved these changes Oct 21, 2025

View reviewed changes

library/alloc/src/collections/vec_deque/spec_extend.rs Outdated Show resolved Hide resolved

implement VecDeque extend_front and prepend, add tests

e23c155

antonilol force-pushed the vec_deque_extend_front branch from d4ae120 to e23c155 Compare November 1, 2025 17:30

This comment has been minimized.

Sign in to view

add specialization for extend_front and prepend with copied slice ite…

5b96677

…rator

antonilol force-pushed the vec_deque_extend_front branch from 4eb54f5 to 5b96677 Compare November 3, 2025 11:36

antonilol requested a review from joboet November 3, 2025 11:39

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 6, 2025

matthiaskrgr mentioned this pull request Nov 6, 2025

Rollup of 10 pull requests #148571

Closed

matthiaskrgr mentioned this pull request Nov 6, 2025

Rollup of 8 pull requests #148572

Closed

matthiaskrgr mentioned this pull request Nov 6, 2025

Rollup of 7 pull requests #148573

Open

GuillaumeGomez mentioned this pull request Nov 6, 2025

Rollup of 9 pull requests #148574

Closed

add extend_front to VecDeque with specialization like extend #146861

Are you sure you want to change the base?

add extend_front to VecDeque with specialization like extend #146861

Conversation

antonilol commented Sep 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

workingjubilee commented Sep 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

the8472 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

the8472 Sep 21, 2025

Choose a reason for hiding this comment

Uh oh!

antonilol Sep 22, 2025

Choose a reason for hiding this comment

Uh oh!

antonilol Sep 28, 2025

Choose a reason for hiding this comment

Uh oh!

the8472 commented Sep 21, 2025

Uh oh!

This comment has been minimized.

Uh oh!

This comment has been minimized.

rustbot commented Sep 30, 2025

Uh oh!

joboet left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bors commented Nov 1, 2025

Uh oh!

rustbot commented Nov 1, 2025

Uh oh!

This comment has been minimized.

joboet commented Nov 6, 2025

Uh oh!

bors commented Nov 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

antonilol commented Sep 21, 2025 •

edited

Loading

workingjubilee commented Sep 21, 2025 •

edited

Loading

the8472 left a comment •

edited by rustbot

Loading

joboet left a comment •

edited by rustbot

Loading