New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for `step_trait` stabilization #42168

Open
scottmcm opened this Issue May 23, 2017 · 6 comments

Comments

Projects
None yet
5 participants
@scottmcm
Member

scottmcm commented May 23, 2017

Split off from #27741 because the stabilization path for step_by has moved to being on iterators (#41439), and thus not using the Step trait.

  • Remove step, steps_between, and is_negative once Range::step_by is deleted
  • Replace replace_zero and replace_one with something more useful (some options: rust-lang/rfcs#1980 (comment))
  • Change steps_between_by_one so that Range<u128> can be TrustedLen (rather than it only working well with types that fit in usize)

(and probably more)

Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue May 23, 2017

Rollup merge of rust-lang#42169 - scottmcm:new-step-trait-issue, r=al…
…excrichton

Give step_trait a distinct tracking issue from step_by

iterator_step_by has decoupled their futures, so the tracking issue should split.

Old issue: rust-lang#27741
New issue: rust-lang#42168

r? @alexcrichton (another follow-up to closed PR rust-lang#42110 (comment))

frewsxcv added a commit to frewsxcv/rust that referenced this issue May 24, 2017

Rollup merge of rust-lang#42169 - scottmcm:new-step-trait-issue, r=al…
…excrichton

Give step_trait a distinct tracking issue from step_by

iterator_step_by has decoupled their futures, so the tracking issue should split.

Old issue: rust-lang#27741
New issue: rust-lang#42168

r? @alexcrichton (another follow-up to closed PR rust-lang#42110 (comment))

frewsxcv added a commit to frewsxcv/rust that referenced this issue May 24, 2017

Rollup merge of rust-lang#42169 - scottmcm:new-step-trait-issue, r=al…
…excrichton

Give step_trait a distinct tracking issue from step_by

iterator_step_by has decoupled their futures, so the tracking issue should split.

Old issue: rust-lang#27741
New issue: rust-lang#42168

r? @alexcrichton (another follow-up to closed PR rust-lang#42110 (comment))

frewsxcv added a commit to frewsxcv/rust that referenced this issue May 26, 2017

Rollup merge of rust-lang#42169 - scottmcm:new-step-trait-issue, r=al…
…excrichton

Give step_trait a distinct tracking issue from step_by

iterator_step_by has decoupled their futures, so the tracking issue should split.

Old issue: rust-lang#27741
New issue: rust-lang#42168

r? @alexcrichton (another follow-up to closed PR rust-lang#42110 (comment))

Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue May 26, 2017

Rollup merge of rust-lang#42169 - scottmcm:new-step-trait-issue, r=al…
…excrichton

Give step_trait a distinct tracking issue from step_by

iterator_step_by has decoupled their futures, so the tracking issue should split.

Old issue: rust-lang#27741
New issue: rust-lang#42168

r? @alexcrichton (another follow-up to closed PR rust-lang#42110 (comment))

frewsxcv added a commit to frewsxcv/rust that referenced this issue May 26, 2017

Rollup merge of rust-lang#42169 - scottmcm:new-step-trait-issue, r=al…
…excrichton

Give step_trait a distinct tracking issue from step_by

iterator_step_by has decoupled their futures, so the tracking issue should split.

Old issue: rust-lang#27741
New issue: rust-lang#42168

r? @alexcrichton (another follow-up to closed PR rust-lang#42110 (comment))

frewsxcv added a commit to frewsxcv/rust that referenced this issue May 26, 2017

Rollup merge of rust-lang#42169 - scottmcm:new-step-trait-issue, r=al…
…excrichton

Give step_trait a distinct tracking issue from step_by

iterator_step_by has decoupled their futures, so the tracking issue should split.

Old issue: rust-lang#27741
New issue: rust-lang#42168

r? @alexcrichton (another follow-up to closed PR rust-lang#42110 (comment))
@scottmcm

This comment has been minimized.

Member

scottmcm commented Jun 9, 2017

Some progress on this in #42534

@SimonSapin

This comment has been minimized.

Contributor

SimonSapin commented Jul 5, 2017

PR #43077 does items 1 and 3 in the original message of this issue.

@SimonSapin

This comment has been minimized.

Contributor

SimonSapin commented Jul 6, 2017

I’ve removed the i128/u128 stuff from my PR because I suspect my mixed-signdeness mixed-width interger arithmetic was buggy. I also massaged the Step trait some more and came up with this:

/// Supporting trait for allowing ranges of various different types to be iterators.
#[unstable(feature = "step_trait",
           reason = "recently redesigned",
           issue = "42168")]
pub trait Step: Clone + PartialOrd + Sized {
    /// Returns the number of steps between two step objects. The count is
    /// inclusive of `start` and exclusive of `end`.
    ///
    /// Returns `None` if it is not possible to calculate `steps_between`
    /// without overflow.
    fn steps_between(start: &Self, end: &Self) -> Option<usize>;

    /// “Go forward” (for integers, add) the given number of steps, returning None on overflow.
    fn forward(&self, step_count: usize) -> Option<Self>;

    /// “Go backward” (for integers, subtract) the given number of steps, returning None on overflow.
    fn backward(&self, step_count: usize) -> Option<Self>;

    /// Modify the given inclusive range so that it becomes empty,
    /// for example by setting it to `1...0`.
    fn make_inclusive_range_empty(range: &mut ops::RangeInclusive<Self>);
}

How does it look?

I’m a bit uncertain of the exact impls for integers, there is up to 6 cases to consider: {smaller, same width, larger} than usize/isize × {signed, unsigned}.

bors added a commit that referenced this issue Jul 8, 2017

Auto merge of #43077 - SimonSapin:ranges, r=alexcrichton
Implement O(1)-time Iterator::nth for Range*, and slim the Step trait

Fixes #43064.
Fixes part of #39975.
Fixes items 1 <s>and 3</s> of #42168.
CC #27741.

I think #42310 and #43012 should not have landed without the `nth` part of this PR, but oh well.
@SimonSapin

This comment has been minimized.

Contributor

SimonSapin commented Jul 8, 2017

I’ve tweaked this design some more and opened #43127. I believe that PR fixes every issue I know of around the Step trait.

@SimonSapin

This comment has been minimized.

Contributor

SimonSapin commented Jul 27, 2017

I’ve closed that PR since it needs more work that I’m not planning to do soon: #43127 (comment). Hopefully someone else can take over.

@pnkfelix

This comment has been minimized.

Member

pnkfelix commented Jul 25, 2018

I just wanted to leave a note saying that if methods with the behavior of fn replace_one/fn replace_zero stay, I hope they have names that look more like fn replace_with_one/fn replace_with_zero, because the way that my head reads the phrase replace_one is "replace one of these" and replace_zero is as "replace zero of these". (Which are both weird things to say in a method, admittedly, but nonetheless, I'd prefer clearer names.)

Having said that, it sounds like these methods are scheduled to be either removed or replaced with something more generally useful?

Update: (maybe if I care about this, I should spend effort reviving PR #43127...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment