Tracking issue for slice_rotate #41891

scottmcm · 2017-05-10T17:16:31Z

Implemented in #41670; merged 2017-06-02.

mbrubeck · 2017-07-06T18:39:18Z

I suggest renaming the method from rotate to rotate_left; otherwise I have trouble remembering exactly what it does either when writing code or when reading it. (If we do this, it would probably also be logical to add a rotate_right method.)

scottmcm · 2017-08-03T07:05:54Z

Bikeshed:

rotate, following Stepanov and McJones, like in C++, also Ruby
rotate_left+rotate_right
bring_to_front, like in D
slide, from Parent, fn(&mut [T], impl RangeArgument, usize) -> Range<usize> (often a nicer signature, but easy to implement using rotate on a subslice, so not necessarily the best primitive)

Edit: Added Ruby

mbrubeck · 2017-08-03T22:02:27Z

More comparison notes:

collections.deque.rotate in Python rotates to the right
rotate_left and rotate_right are used in Rust for bitwise rotation

jethrogb · 2017-08-10T04:47:09Z

The doc text links to non-free documentation. Can we find a publicly available source to link to?

frewsxcv · 2017-12-16T22:08:13Z

Opened a pull request for introducing rotate_{left,right}: #46777

Background ========== Slices currently have an unstable [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate(2); assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate_left(2); assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']); ``` ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate_right(2); assert_eq!(a, ['e', 'f', 'a', 'b', 'c', 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward, Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: rust-lang#41891

…chton Deprecate [T]::rotate in favor of [T]::rotate_{left,right}. Background ========== Slices currently have an **unstable** [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate(2); assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate_left(2); assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']); ``` ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate_right(2); assert_eq!(a, ['e', 'f', 'a', 'b', 'c', 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward, Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. The current `rotate` implementation takes an unsigned integer argument which doesn't allow the negative number behavior. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: rust-lang#41891

whitequark · 2018-02-22T10:04:34Z

What's the timeline for stabilizing this?

scottmcm · 2018-02-22T23:50:07Z

I think @frewsxcv's PR resolved the questions from the original implementation (naming, return value, and docs), so maybe as soon as someone makes a stabilization PR (for 1.26, I guess?).

frewsxcv · 2018-02-23T00:55:04Z

stabilization pr: #48450

rust-lang#41891

…rotatee, r=alexcrichton Stabilize [T]::rotate_{left,right} rust-lang#41891

frewsxcv · 2018-02-28T15:37:05Z

stabilization pull request just merged, so i think this can be closed now

Background ========== Slices currently have an unstable [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate(2); assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate_left(2); assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']); ``` ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate_right(2); assert_eq!(a, ['e', 'f', 'a', 'b', 'c', 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward, Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: rust-lang/rust#41891

Deprecate [T]::rotate in favor of [T]::rotate_{left,right}. Background ========== Slices currently have an **unstable** [`rotate`] method which rotates elements in the slice to the _left_ N positions. [Here][tracking] is the tracking issue for this unstable feature. ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate(2); assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']); ``` Proposal ======== Deprecate the [`rotate`] method and introduce `rotate_left` and `rotate_right` methods. ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate_left(2); assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']); ``` ```rust let mut a = ['a', 'b' ,'c', 'd', 'e', 'f']; a.rotate_right(2); assert_eq!(a, ['e', 'f', 'a', 'b', 'c', 'd']); ``` Justification ============= I used this method today for my first time and (probably because I’m a naive westerner who reads LTR) was surprised when the docs mentioned that elements get rotated in a left-ward direction. I was in a situation where I needed to shift elements in a right-ward direction and had to context switch from the main problem I was working on and think how much to rotate left in order to accomplish the right-ward rotation I needed. Ruby’s `Array.rotate` shifts left-ward, Python’s `deque.rotate` shifts right-ward. Both of their implementations allow passing negative numbers to shift in the opposite direction respectively. The current `rotate` implementation takes an unsigned integer argument which doesn't allow the negative number behavior. Introducing `rotate_left` and `rotate_right` would: - remove ambiguity about direction (alleviating need to read docs 😉) - make it easier for people who need to rotate right [`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate [tracking]: rust-lang/rust#41891

nagisa added B-unstable Blocker: Implemented in the nightly compiler and unstable. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels May 11, 2017

Mark-Simulacrum added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Jul 22, 2017

frewsxcv mentioned this issue Dec 16, 2017

Deprecate [T]::rotate in favor of [T]::rotate_{left,right}. #46777

Merged

whitequark mentioned this issue Feb 14, 2018

Factor wire module out into its own crate? smoltcp-rs/smoltcp#162

Closed

frewsxcv mentioned this issue Feb 23, 2018

Stabilize [T]::rotate_{left,right} #48450

Merged

frewsxcv added a commit to frewsxcv/rust that referenced this issue Feb 23, 2018

Stabilize [T]::rotate_{left,right}

b1a6c8b

rust-lang#41891

kennytm added a commit to kennytm/rust that referenced this issue Feb 27, 2018

Rollup merge of rust-lang#48450 - frewsxcv:frewsxcxv-stabilize-slice-…

b106016

…rotatee, r=alexcrichton Stabilize [T]::rotate_{left,right} rust-lang#41891

kennytm added a commit to kennytm/rust that referenced this issue Feb 28, 2018

Rollup merge of rust-lang#48450 - frewsxcv:frewsxcxv-stabilize-slice-…

ef44e63

…rotatee, r=alexcrichton Stabilize [T]::rotate_{left,right} rust-lang#41891

frewsxcv closed this as completed Feb 28, 2018

scottmcm mentioned this issue Dec 17, 2018

Add unstable VecDeque::rotate_{left|right} #56842

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for slice_rotate #41891

Tracking issue for slice_rotate #41891

scottmcm commented May 10, 2017 •

edited

Loading

mbrubeck commented Jul 6, 2017

scottmcm commented Aug 3, 2017 •

edited

Loading

mbrubeck commented Aug 3, 2017

jethrogb commented Aug 10, 2017

frewsxcv commented Dec 16, 2017

whitequark commented Feb 22, 2018

scottmcm commented Feb 22, 2018

frewsxcv commented Feb 23, 2018

frewsxcv commented Feb 28, 2018

Tracking issue for slice_rotate #41891

Tracking issue for slice_rotate #41891

Comments

scottmcm commented May 10, 2017 • edited Loading

mbrubeck commented Jul 6, 2017

scottmcm commented Aug 3, 2017 • edited Loading

mbrubeck commented Aug 3, 2017

jethrogb commented Aug 10, 2017

frewsxcv commented Dec 16, 2017

whitequark commented Feb 22, 2018

scottmcm commented Feb 22, 2018

frewsxcv commented Feb 23, 2018

frewsxcv commented Feb 28, 2018

scottmcm commented May 10, 2017 •

edited

Loading

scottmcm commented Aug 3, 2017 •

edited

Loading