.rev() method on RangeTo?

community
1

RangeTo and RangeToInclusive don't implements Iterator, so this fails to compile:

for i in (..=10) { }

But it would be nice if we could write as:

for i in (..=10).rev() {
    print!("{} ", i);
    if i == 5 {
        break;
    }
}

The expected result is 10 9 8 7 6 5.

There seem to be two ways to make it possible:

  • just add .rev() method to RangeTo and RangeToInclusive (where Idx: Step).
  • separate DoubleEndedIterator into two traits, Iterator and ReverseIterator, as pointed out in this issue.

I wonder:

  • Are there any other ways?
  • Would the latter one be a breaking change?
1 Like
2

For comparison, hereā€™s one solution that currently works:

std::iter::repeat_with({
    let mut i = 10;
    move || (i, i -= 1).0
})

(hereā€™s a test in the playground)

which is indeed quite lengthy. Iā€™m curious if thereā€™s better approaches that Iā€™m missing.

3 
fn countdown(n: i32) -> impl Iterator<Item = i32> {
    std::iter::successors(Some(n), |&n| Some(n - 1))
}

Playground.
successors documentation.

1 Like
4

or (0..).map(|i| n - i)态

3 Likes
5

Note that this one over/underflows in a different part of the iteration (but behaves the same when wrapping).

1 Like
6

And I think (i32::MIN..=10).rev() also works in most cases. But it is still fascinating to me to realize (..=10).rev(), because it is so clear what it means.

1 Like
7

Note that this one wonā€™t have the infinite size_hint and TrustedLen impl that repeat_with or n.. does have.

2 Likes
8

I beg to differ. The documentation explicitly states that the problem is it's got no beginning. So how would .rev() decide when to stop? If you want (0..=10).rev() or i32::MIN..=10).rev() then you should write that. It is clear enough.

3 Likes
9

It doesnā€™t stop, thatā€™s the whole point. Just like 42.. doesnā€™t stop.

The iterator is infinite; naturally it can eventually overflow because the integer range is finite, resulting in wrap-around on release mode, or panic in debug mode. But it saves the bounds check, which is why itā€™s useful, I guess.

5 Likes
10

Yes, because you can't implement supertrait methods in an subtrait impl block.

Hmm, with negative impl coherence you could even have rev on RangeTo<T> return Rev<RangeTo<T>>, and then implement Iterator for Rev<RangeTo<T>>...

11

No, I don't think that's correct. 42.. already doesn't stop by itself, but ..42 doesn't begin anywhere. However, it would have to have a definite first element in order to be an iterator in the first place, so the stdlib is perfectly correct in observing this ā€“ perhaps counter-intuitive, but technically necessary ā€“ asymmetry.

12

This seems like a fixable problem. I'm currently (slowly) starting to work on some RFC at the moment that should make such changes possible in a non-breaking manner; good to have another (potential) example use-case here.

1 Like
13

We are talking about implementing Iterator on (..=10).rev(), not ..=10 itself.
And (..=10).rev() has the first element: 10.

14

Yes, I get that, but then .rev() would need to be a non-Iterator method.

15

So I proposed two ways: (1) adding RangeTo::rev() method apart from Iterator::rev(), or (2) splitting DoubleEndedIterator into Iterator and ReverseIterator.
In fact I don't have a concrete idea for (2) without breaking changes, though.

16

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.