Tracking issue for VecDeque::rotate_{left|right} (feature vecdeque_rotate)

[DutchGhost]

Currently if you want to rotate a VecDeque n elements to the left or right, you'd have to write something like this:

use std::collections::VecDeque;

fn main() {
    let mut v = (0..10).collect::<VecDeque<_>>();
    
    println!("{:?}", v); // [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
    
    // rotate left by 2,
    for _ in 0..2 {
        if let Some(popped_front) = v.pop_front() {
            v.push_back(popped_front);
        }
    }
    
    println!("{:?}", v); // [2, 3, 4, 5, 6, 7, 8, 9, 0, 1]
    
    // rotate right by 4
    for _ in 0..4 {
        if let Some(popped_back) = v.pop_back() {
            v.push_front(popped_back);
        }
    }
    
    println!("{:?}", v); //[8, 9, 0, 1, 2, 3, 4, 5, 6, 7]
    
}

I wonder if it would be possible to add 2 functions:

• rotate_left(mid: usize)
• rotate_right(mid: usize)

You then only have to write:

use std::collections::VecDeque;

fn main() {
    let mut v = (0..10).collect::<VecDeque<_>>();
    
    println!("{:?}", v); // [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
    
    // rotate left by 2,
    v.rotate_left(2)
    println!("{:?}", v); // [2, 3, 4, 5, 6, 7, 8, 9, 0, 1]
    
    // rotate right by 4
    v.rotate_right(4);
    
    println!("{:?}", v); //[8, 9, 0, 1, 2, 3, 4, 5, 6, 7]
    
}

This would be equal to slice's rotate_left and rotate_right.
It could probably be implemented on a lower level than with pop's and pushes for a little more efficiency.

[scottmcm]

Ooh, I like this -- VecDeque is a circular buffer internally, so it should be doable with just a single at most two ptr::copy. EDIT: PR #56842

[scottmcm]

PR is r+'d, so I turned this into a tracking issue.

[DutchGhost]

I've since the feature replaced any code that used the pop - push technique with the rotate methods. This was fairly easy to do.

It's been a few months now, are there any issue's preventing this from landing stable?

[sfackler]

@rfcbot fcp merge

[rfcbot]

Team member @sfackler has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @Kimundi
• @SimonSapin
• @alexcrichton
• @dtolnay
• @sfackler
• @withoutboats

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.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[WiSaGaN]

Is "left" or "right" the word we want to use here? Previously we have deprecated trim_left (trim_right) of String in favor of trim_start and trim_end so that we do not assume the string is laid out from left to right. Here we seem to assume left is to front while right is to back? Are we able to use some words that express the front and back without assuming a left-to-right layout?

[DutchGhost]

As discussed here, we have to use those names to stay consistent with the slice rotate_{left |right} methods #56842 (comment)

[WiSaGaN]

@DutchGhost , sorry I missed that. That makes sense.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.