Redesign the std::iter::Step trait, tweak related iterator impls for ranges #43127

SimonSapin · 2017-07-08T20:10:23Z

The trait is now:

/// Objects that have a notion of *successor* and *predecessor*
/// for the purpose of range iterators.
///
/// This trait is `unsafe` because implementations of the `unsafe` trait `TrustedLen`
/// depend on its implementations being correct.
#[unstable(feature = "step_trait",
           reason = "recently redesigned",
           issue = "42168")]
pub unsafe trait Step: Clone + PartialOrd + Sized {
    /// Returns the number of *successor* steps needed to get from `start` to `end`.
    ///
    /// Returns `None` if that number would overflow `usize`
    /// (or is infinite, if `end` would never be reached).
    ///
    /// This must hold for any `a`, `b`, and `n`:
    ///
    /// * `steps_between(&a, &b) == Some(0)` if and only if `a >= b`.
    /// * `steps_between(&a, &b) == Some(n)` if and only if `a.forward(n) == Some(b)`
    /// * `steps_between(&a, &b) == Some(n)` if and only if `b.backward(n) == Some(a)`
    fn steps_between(start: &Self, end: &Self) -> Option<usize>;

    /// Returns the value that would be obtained by taking the *successor* of `self`,
    /// `step_count` times.
    ///
    /// Returns `None` if this would overflow the range of values supported by the type `Self`.
    ///
    /// Note: `step_count == 1` is a common case,
    /// used for example in `Iterator::next` for ranges.
    ///
    /// This must hold for any `a`, `n`, and `m` where `n + m` doesn’t overflow:
    ///
    /// * `a.forward(n).and_then(|x| x.forward(m)) == a.forward(n + m)`
    fn forward(&self, step_count: usize) -> Option<Self>;

    /// Returns the value that would be obtained by taking the *predecessor* of `self`,
    /// `step_count` times.
    ///
    /// Returns `None` if this would overflow the range of values supported by the type `Self`.
    ///
    /// Note: `step_count == 1` is a common case,
    /// used for example in `Iterator::next_back` for ranges.
    ///
    /// This must hold for any `a`, `n`, and `m` where `n + m` doesn’t overflow:
    ///
    /// * `a.backward(n).and_then(|x| x.backward(m)) == a.backward(n + m)`
    fn backward(&self, step_count: usize) -> Option<Self>;
}

Arithmetic and overflow handling with multiple integer types of different widths and signedness is tricky, careful review would be appreciated.

Other changes:

The unsafe trait TrustedLen is now implemented for ranges of ~~all integer types~~ all T: Step types. Step is now an unsafe trait as a consequence.
Check for overflow everywhere. If it turns out the optimizer doesn’t manage to elide some of the checks that could be removed I’ll leave it to someone else to carefully optimize this, preferably without changing behavior. CC The new step_by is too much slow #43064
Remove ExactSizeIterator impls for RangeInclusive<u16> and RangeInclusive<i16> as they are incorrect on 16-bit platforms. CC Stabilize the inclusive_range lib feature #43086 (comment)
Don’t reset inclusive ranges to 1...0 after the last iteration. Instead increment or decrement similarly to other iterations. If that would cause overflow, decrement/increment the other bound instead.
Return (usize::MAX, None) instead of (0, None) in size_hint when the exact result would overflow usize.

rust-highfive · 2017-07-08T20:10:28Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @aturon (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

SimonSapin · 2017-07-09T10:01:38Z

https://travis-ci.org/rust-lang/rust/jobs/251678510 "env": "IMAGE=x86_64-gnu-llvm-3.7 ALLOW_PR=1 RUST_BACKTRACE=1"

error: linking with `cc` failed: exit code: 1
[…]
undefined reference to `core::option::expect_failed::h6f9984c44d33d89c

🤔

kennytm · 2017-07-09T17:40:01Z

Merging this as-is would make the situation in #43124 even worse — the speed of (0 .. u16::MAX).collect::<Vec<_>>() is reduced from ~110µs/iter to ~170µs/iter.

Edit: However, changing the implementation of forward() from:

                #[inline]
                fn forward(&self, n: usize) -> Option<Self> {
                    match Self::try_from(n) {
                        Ok(n_converted) => self.checked_add(n_converted),
                        Err(_) => None,  // if n is out of range, `something_unsigned + n` is too
                    }
                }

to:

    #[inline]
    fn forward(&self, n: usize) -> Option<Self> {
        if n <= u16::MAX as usize {
            self.checked_add(n as u16)
        } else {
            None
        }
    }

would immediately fix #43124 (speed becomes ~4µs/iter). I don't understand what LLVM is thinking 🤔

Edit²: Putting the TryFrom definition directly inside the user crate also fixes the issue. Some inlining magic?

oyvindln · 2017-07-09T19:29:21Z

I don't understand what LLVM is thinking

The impl for TryFrom casts the value to i/u128 to check if it's in range, maybe that is something that could cause issues as the 128-bit types are somewhat special.

SimonSapin · 2017-07-09T21:48:09Z

I think the current state of this PR is about the amount of effort I’m willing to put into this at the moment. If anyone would like to pick it up and push on the optimization front, feel free.

(I think going through 128-bit ints in TryFrom is unnecessary if we use separate code for size_of::<$Source>() < size_of::<$Destination>() vs size_of::<$Source>() > size_of::<$Destination>().)

carols10cents · 2017-07-10T12:41:15Z

o.O I'm not sure why travis is failing like this with linking problems: https://travis-ci.org/rust-lang/rust/jobs/251678510#L1044

I tried restarting that job to make sure it wasn't something intermittent but it just failed in the same way again...

do you have any ideas why this might be happening for this PR @SimonSapin ?

ExpHP · 2017-07-10T12:54:13Z

/// Returns the number of *successor* steps needed to get from `start` to `end`.
///
/// Returns `None` if that number would overflow `usize`
/// (or is infinite, if `end` would never be reached).
///
/// This must hold for any `a`, `b`, and `n`:
///
/// * `steps_between(&a, &b) == Some(0)` if and only if `a >= b`.
/// * `steps_between(&a, &b) == Some(n)` if and only if `a.forward(n) == Some(b)`
/// * `steps_between(&a, &b) == Some(n)` if and only if `b.backward(n) == Some(a)`

Surely this couId be better worded. I had to read this docstring very carefully to convince myself that it does indeed follow the typical rust semantics of half-open ranges, and that e.g. steps_between(&0, &n) == Some(n)

SimonSapin · 2017-07-10T12:59:47Z

@carols10cents On IRC @eddyb said it’s probably because intrinsics for u128 divison use a range iterator but are not allowed to link to panic code, and this PR adds calls to Option::expect in range iterator implementations. (Even if these "should" never panic, merely linking causes issues if that code is not optimized away.)

So it sounds like this needs more work to have correct overflow semantics without using panicking code.

@ExpHP I don’t mind rewriting this if you have a suggestion how. I avoided talking about addition and subtraction because Step can be implemented for things that are not necessarily numbers.

ExpHP · 2017-07-10T13:08:03Z

@ExpHP I don’t mind rewriting this if you have a suggestion how. I avoided talking about addition and subtraction because Step can be implemented for things that are not necessarily numbers.

I would suggest making reference to the "length of the range a..b," which should already be readily familiar to almost any reader, and also places the trait in context of where it is used. As far as I can tell, the only difference is that sometimes this function returns None.

scottmcm · 2017-07-15T23:15:20Z

src/libcore/iter/range.rs

+        // This seems redundant with a similar comparison that `Step::steps_between`
+        // implementations need to do, but it separates the `start > end` case from `start == end`.
+        // `steps_between` returns `Some(0)` in both of these cases, but we only want to add 1
+        // in the latter.


Should steps_between perhaps instead return something like Result<Option<usize>, Unreachable>? Might make the documentation for the method easier to write, too.

scottmcm · 2017-07-15T23:20:46Z

src/libcore/iter/range.rs

+    /// Returns `None` if this would overflow the range of values supported by the type `Self`.
+    ///
+    /// Note: `step_count == 1` is a common case,
+    /// used for example in `Iterator::next` for ranges.


Would it be worth a fn forward_one(&self) -> Option<Self> { self.forward(1) } (or call it successor, perhaps, like the comment here does) so the common case is overridable if needed? I suppose it's always addable later if needed.

scottmcm · 2017-07-15T23:30:21Z

src/libcore/iter/range.rs

@@ -280,7 +353,8 @@ impl<A: Step> Iterator for ops::RangeFrom<A> {

    #[inline]
    fn next(&mut self) -> Option<A> {
-        let mut n = self.start.add_one();
+        // Overflow can happen here. Panic when it does.
+        let mut n = self.start.forward(1).expect("overflow in RangeFrom::next");


IIRC this used to only panic in debug, right?

I like the change, but it might need to be called out in documentation somewhere.

scottmcm · 2017-07-15T23:46:30Z

Thanks for picking this up, @SimonSapin! The trait looks way better now.

Some general musings on the trait:

steps_between is very similar to PartialOrd::cmp, and could be a superset. It might be interesting to remove the need for PartialOrd using that fact.
Some of the range RFCs talked about ranges of slightly weird things like singly-linked list or DAG nodes which don't have computable or unique predecessors (respectively). Would it be worth splitting the trait in two, like iterator? (Now, I have no idea how to efficiently implement steps_between for those things, so it might be a moot point.)

SimonSapin · 2017-07-16T00:10:16Z

Some of the range RFCs talked about ranges of slightly weird things like singly-linked list or DAG nodes which don't have computable or unique predecessors (respectively). Would it be worth splitting the trait in two, like iterator?

So things that have a successor but no predecessor? Yes, this would require a trait separate from Step for the DoubleEndedIterator impl. But honestly this sounds so niche that I’m not convinced std should "go out of its way" to support it. Libraries with such types can define their own ranges and iterators.

carols10cents · 2017-07-24T12:43:49Z

friendly ping to keep this on your radar @SimonSapin !

Instead try to set start to end+1, and if that overflows set end to start-1.

They are incorrect on 16-bit platforms since the return value of `len()` might overflow `usize`. Impls for `Range<u32>` and `Range<i32>` are similarly incorrect, but were stabilized in Rust 1.0.0 so removing them would be a breaking change. `(0..66_000_u32).len()` for example will compile without error or warnings on 16-bit platforms, but panic at run-time.

…rait.

SimonSapin · 2017-07-24T13:45:33Z

My understanding is that the main concern at this point is performance, and I wrote:

#43127 (comment)

I think the current state of this PR is about the amount of effort I’m willing to put into this at the moment. If anyone would like to pick it up and push on the optimization front, feel free.

As to the CI failure, it might be fixed by #43258. I’ve pushed a rebase to trigger a new build.

SimonSapin · 2017-07-24T14:20:44Z

Perf might be worth re-evaluating once #43248 or #43194 lands.

alexcrichton · 2017-07-27T23:19:57Z

ping @aturon for a review!

SimonSapin · 2017-07-27T23:53:14Z

This needs some more work that I’m not planning to do soon, closing to make that clear. Hopefully someone else can take over.

In one Travis-CI configuration, "Building stage0 compiler artifacts" is failing at link-time with errors like undefined reference to `core::option::expect_failed::h6f9984c44d33d89c'. Eddyb said this might be because u128 division intrinsics use range iterators, and intrinsics are not allowed to link to panicking code. This PR introduces usage of Option::expect in range iterators, although for primitive integers types these should never panic (unless libcore is buggy). I think removing usage of Option::expect would require making the Step trait more complex, effectively undoing some of what this PR does. Maybe the intrinsics can be changed to not use range iterators instead?
Several people have expressed concerns about performance. This needs benchmarking to see if this PR regresses it, maybe analyzing assembly code to figure out why and what can be done about it. If it turns out that overflow checking is responsible, consider how much overflow checking is desirable.

Add an overflow check in the Iter::next() impl for Range<_> to help with vectorization. This helps with vectorization in some cases, such as (0..u16::MAX).collect::<Vec<u16>>(), as LLVM is able to change the loop condition to use equality instead of less than and should help with #43124. (See also my [last comment](#43124 (comment)) there.) This PR makes collect on ranges of u16, i16, i8, and u8 **significantly** faster (at least on x86-64 and i686), and pretty close, though not quite equivalent to a [manual unsafe implementation](https://is.gd/nkoecB). 32 ( and 64-bit values on x86-64) bit values were already vectorized without this change, and they still are. This PR doesn't seem to help with 64-bit values on i686, as they still don't vectorize well compared to doing a manual loop. I'm a bit unsure if this was the best way of implementing this, I tried to do it with as little changes as possible and avoided changing the step trait and the behavior in RangeFrom (I'll leave that for others like #43127 to discuss wider changes to the trait). I tried simply changing the comparison to `self.start != self.end` though that made the compiler segfault when compiling stage0, so I went with this method instead for now. As for `next_back()`, reverse ranges seem to optimise properly already.

Rework the std::iter::Step trait Previous attempts: rust-lang#43127 rust-lang#62886 rust-lang#68807 Tracking issue: rust-lang#42168 This PR reworks the `Step` trait to be phrased in terms of the *successor* and *predecessor* operations. With this, `Step` hopefully has a consistent identity that can have a path towards stabilization. The proposed trait: ```rust /// Objects that have a notion of *successor* and *predecessor* operations. /// /// The *successor* operation moves towards values that compare greater. /// The *predecessor* operation moves towards values that compare lesser. /// /// # Safety /// /// This trait is `unsafe` because its implementation must be correct for /// the safety of `unsafe trait TrustedLen` implementations, and the results /// of using this trait can otherwise be trusted by `unsafe` code to be correct /// and fulful the listed obligations. pub unsafe trait Step: Clone + PartialOrd + Sized { /// Returns the number of *successor* steps required to get from `start` to `end`. /// /// Returns `None` if the number of steps would overflow `usize` /// (or is infinite, or if `end` would never be reached). /// /// # Invariants /// /// For any `a`, `b`, and `n`: /// /// * `steps_between(&a, &b) == Some(n)` if and only if `Step::forward(&a, n) == Some(b)` /// * `steps_between(&a, &b) == Some(n)` if and only if `Step::backward(&a, n) == Some(a)` /// * `steps_between(&a, &b) == Some(n)` only if `a <= b` /// * Corollary: `steps_between(&a, &b) == Some(0)` if and only if `a == b` /// * Note that `a <= b` does _not_ imply `steps_between(&a, &b) != None`; /// this is the case wheen it would require more than `usize::MAX` steps to get to `b` /// * `steps_between(&a, &b) == None` if `a > b` fn steps_between(start: &Self, end: &Self) -> Option<usize>; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self`, returns `None`. /// /// # Invariants /// /// For any `a`, `n`, and `m`: /// /// * `Step::forward_checked(a, n).and_then(|x| Step::forward_checked(x, m)) == Step::forward_checked(a, m).and_then(|x| Step::forward_checked(x, n))` /// /// For any `a`, `n`, and `m` where `n + m` does not overflow: /// /// * `Step::forward_checked(a, n).and_then(|x| Step::forward_checked(x, m)) == Step::forward_checked(a, n + m)` /// /// For any `a` and `n`: /// /// * `Step::forward_checked(a, n) == (0..n).try_fold(a, |x, _| Step::forward_checked(&x, 1))` /// * Corollary: `Step::forward_checked(&a, 0) == Some(a)` fn forward_checked(start: Self, count: usize) -> Option<Self>; /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self`, /// this function is allowed to panic, wrap, or saturate. /// The suggested behavior is to panic when debug assertions are enabled, /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a`, `n`, and `m`, where no overflow occurs: /// /// * `Step::forward(Step::forward(a, n), m) == Step::forward(a, n + m)` /// /// For any `a` and `n`, where no overflow occurs: /// /// * `Step::forward_checked(a, n) == Some(Step::forward(a, n))` /// * `Step::forward(a, n) == (0..n).fold(a, |x, _| Step::forward(x, 1))` /// * Corollary: `Step::forward(a, 0) == a` /// * `Step::forward(a, n) >= a` /// * `Step::backward(Step::forward(a, n), n) == a` fn forward(start: Self, count: usize) -> Self { Step::forward_checked(start, count).expect("overflow in `Step::forward`") } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow, use `forward` or `forward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b > a`, it is safe to call `Step::forward_unchecked(a, 1)` /// * if there exists `b`, `n` such that `steps_between(&a, &b) == Some(n)`, /// it is safe to call `Step::forward_unchecked(a, m)` for any `m <= n`. /// /// For any `a` and `n`, where no overflow occurs: /// /// * `Step::forward_unchecked(a, n)` is equivalent to `Step::forward(a, n)` #[unstable(feature = "unchecked_math", reason = "niche optimization path", issue = "none")] unsafe fn forward_unchecked(start: Self, count: usize) -> Self { Step::forward(start, count) } /// Returns the value that would be obtained by taking the *successor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self`, returns `None`. /// /// # Invariants /// /// For any `a`, `n`, and `m`: /// /// * `Step::backward_checked(a, n).and_then(|x| Step::backward_checked(x, m)) == n.checked_add(m).and_then(|x| Step::backward_checked(a, x))` /// * `Step::backward_checked(a, n).and_then(|x| Step::backward_checked(x, m)) == try { Step::backward_checked(a, n.checked_add(m)?) }` /// /// For any `a` and `n`: /// /// * `Step::backward_checked(a, n) == (0..n).try_fold(a, |x, _| Step::backward_checked(&x, 1))` /// * Corollary: `Step::backward_checked(&a, 0) == Some(a)` fn backward_checked(start: Self, count: usize) -> Option<Self>; /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// If this would overflow the range of values supported by `Self`, /// this function is allowed to panic, wrap, or saturate. /// The suggested behavior is to panic when debug assertions are enabled, /// and to wrap or saturate otherwise. /// /// Unsafe code should not rely on the correctness of behavior after overflow. /// /// # Invariants /// /// For any `a`, `n`, and `m`, where no overflow occurs: /// /// * `Step::backward(Step::backward(a, n), m) == Step::backward(a, n + m)` /// /// For any `a` and `n`, where no overflow occurs: /// /// * `Step::backward_checked(a, n) == Some(Step::backward(a, n))` /// * `Step::backward(a, n) == (0..n).fold(a, |x, _| Step::backward(x, 1))` /// * Corollary: `Step::backward(a, 0) == a` /// * `Step::backward(a, n) <= a` /// * `Step::forward(Step::backward(a, n), n) == a` fn backward(start: Self, count: usize) -> Self { Step::backward_checked(start, count).expect("overflow in `Step::backward`") } /// Returns the value that would be obtained by taking the *predecessor* /// of `self` `count` times. /// /// # Safety /// /// It is undefined behavior for this operation to overflow the /// range of values supported by `Self`. If you cannot guarantee that this /// will not overflow, use `backward` or `backward_checked` instead. /// /// # Invariants /// /// For any `a`: /// /// * if there exists `b` such that `b < a`, it is safe to call `Step::backward_unchecked(a, 1)` /// * if there exists `b`, `n` such that `steps_between(&b, &a) == Some(n)`, /// it is safe to call `Step::backward_unchecked(a, m)` for any `m <= n`. /// /// For any `a` and `n`, where no overflow occurs: /// /// * `Step::backward_unchecked(a, n)` is equivalent to `Step::backward(a, n)` #[unstable(feature = "unchecked_math", reason = "niche optimization path", issue = "none")] unsafe fn backward_unchecked(start: Self, count: usize) -> Self { Step::backward(start, count) } } ``` Note that all of these are associated functions and not callable via method syntax; the calling syntax is always `Step::forward(start, n)`. This version of the trait additionally changes the stepping functions to talk their arguments by value. As opposed to previous attempts which provided a "step by one" method directly, this version of the trait only exposes "step by n". There are a few reasons for this: - `Range*`, the primary consumer of `Step`, assumes that the "step by n" operation is cheap. If a single step function is provided, it will be a lot more enticing to implement "step by n" as n repeated calls to "step by one". While this is not strictly incorrect, this behavior would be surprising for anyone used to using `Range<{primitive integer}>`. - With a trivial default impl, this can be easily added backwards-compatibly later. - The debug-wrapping "step by n" needs to exist for `RangeFrom` to be consistent between "step by n" and "step by one" operation. (Note: the behavior is not changed by this PR, but making the behavior consistent is made tenable by this PR.) Three "kinds" of step are provided: `_checked`, which returns an `Option` indicating attempted overflow; (unsuffixed), which provides "safe overflow" behavior (is allowed to panic, wrap, or saturate, depending on what is most convenient for a given type); and `_unchecked`, which is a version which assumes overflow does not happen. Review is appreciated to check that: - The invariants as described on the `Step` functions are enough to specify the "common sense" consistency for successor/predecessor. - Implementation of `Step` functions is correct in the face of overflow and the edges of representable integers. - Added tests of `Step` functions are asserting the correct behavior (and not just the implemented behavior).

rust-highfive assigned aturon Jul 8, 2017

This was referenced Jul 8, 2017

Tracking issue for step_trait stabilization #42168

Open

Tracking issue for step_by stabilization #27741

Closed

frewsxcv added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jul 9, 2017

SimonSapin force-pushed the ranges branch 2 times, most recently from d6e1fd7 to 24cd69a Compare July 9, 2017 09:34

SimonSapin mentioned this pull request Jul 9, 2017

The new step_by is too much slow #43064

Closed

oyvindln mentioned this pull request Jul 9, 2017

Collect<Vec<u16>> from range doesn't optimize well. #43124

Closed

carols10cents added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 10, 2017

oyvindln mentioned this pull request Jul 10, 2017

Tracking issue for TryFrom/TryInto traits #33417

Closed

3 tasks

carols10cents added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 10, 2017

oyvindln mentioned this pull request Jul 12, 2017

Add inline annotations and avoid 128-bit where it's not needed in TryFrom + tests for xsize/x128 #43194

Closed

scottmcm reviewed Jul 15, 2017

View reviewed changes

SimonSapin added 2 commits July 24, 2017 15:43

Check integer overflow/underflow in Range* iterators

d103522

Don’t reset RangeInclusive to 1...0 after last iteration.

3e8a762

Instead try to set start to end+1, and if that overflows set end to start-1.

SimonSapin added 7 commits July 24, 2017 15:43

Add tests for Step trait methods

9d4dc29

Implement TrustedLen for ranges of all integer types

c0b4440

Tighter size_hint lower bound for ranges larger than usize

b270e7f

Add a comment on the start > end check in RangeInclusive::size_hint

eed9884

Make tidy happy

0a62269

Implement TrustedLen for ranges of all T: Step, make Step an unsafe t…

0ac7fca

…rait.

SimonSapin force-pushed the ranges branch from 24cd69a to 0ac7fca Compare July 24, 2017 13:44

alexcrichton added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 27, 2017

SimonSapin closed this Jul 27, 2017

oyvindln mentioned this pull request Aug 1, 2017

Add an overflow check in the Iter::next() impl for Range<_> to help with vectorization. #43595

Merged

scottmcm mentioned this pull request Apr 2, 2019

Implement useful steps_between for all integers #59444

Merged

CAD97 mentioned this pull request Aug 6, 2019

Redesign the std::iter::Step trait #62886

Closed

CAD97 mentioned this pull request Feb 3, 2020

Redesign the std::iter::Step trait #68807

Closed

CAD97 mentioned this pull request Mar 3, 2020

Rework the std::iter::Step trait #69659

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Redesign the std::iter::Step trait, tweak related iterator impls for ranges #43127

Redesign the std::iter::Step trait, tweak related iterator impls for ranges #43127

SimonSapin commented Jul 8, 2017 •

edited

Loading

rust-highfive commented Jul 8, 2017

SimonSapin commented Jul 9, 2017

kennytm commented Jul 9, 2017 •

edited

Loading

oyvindln commented Jul 9, 2017 •

edited

Loading

SimonSapin commented Jul 9, 2017

carols10cents commented Jul 10, 2017

ExpHP commented Jul 10, 2017 •

edited

Loading

SimonSapin commented Jul 10, 2017

ExpHP commented Jul 10, 2017

scottmcm Jul 15, 2017 •

edited

Loading

scottmcm Jul 15, 2017 •

edited

Loading

scottmcm Jul 15, 2017

scottmcm commented Jul 15, 2017

SimonSapin commented Jul 16, 2017

carols10cents commented Jul 24, 2017

SimonSapin commented Jul 24, 2017

SimonSapin commented Jul 24, 2017

alexcrichton commented Jul 27, 2017

SimonSapin commented Jul 27, 2017

Redesign the std::iter::Step trait, tweak related iterator impls for ranges #43127

Redesign the std::iter::Step trait, tweak related iterator impls for ranges #43127

Conversation

SimonSapin commented Jul 8, 2017 • edited Loading

rust-highfive commented Jul 8, 2017

SimonSapin commented Jul 9, 2017

kennytm commented Jul 9, 2017 • edited Loading

oyvindln commented Jul 9, 2017 • edited Loading

SimonSapin commented Jul 9, 2017

carols10cents commented Jul 10, 2017

ExpHP commented Jul 10, 2017 • edited Loading

SimonSapin commented Jul 10, 2017

ExpHP commented Jul 10, 2017

scottmcm Jul 15, 2017 • edited Loading

Choose a reason for hiding this comment

scottmcm Jul 15, 2017 • edited Loading

Choose a reason for hiding this comment

scottmcm Jul 15, 2017

Choose a reason for hiding this comment

scottmcm commented Jul 15, 2017

SimonSapin commented Jul 16, 2017

carols10cents commented Jul 24, 2017

SimonSapin commented Jul 24, 2017

SimonSapin commented Jul 24, 2017

alexcrichton commented Jul 27, 2017

SimonSapin commented Jul 27, 2017

SimonSapin commented Jul 8, 2017 •

edited

Loading

kennytm commented Jul 9, 2017 •

edited

Loading

oyvindln commented Jul 9, 2017 •

edited

Loading

ExpHP commented Jul 10, 2017 •

edited

Loading

scottmcm Jul 15, 2017 •

edited

Loading

scottmcm Jul 15, 2017 •

edited

Loading