f7f128fd48
add extend_front to VecDeque with specialization like extend ACP: https://github.com/rust-lang/libs-team/issues/658 Tracking issue: rust-lang/rust#146975 _Text below was written before opening the ACP_ Feature was requested in rust-lang/rust#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 https://github.com/rust-lang/rust/pull/146861#pullrequestreview-3250163369 - 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. |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||