Taking exact number of elements from range iterator causes interger overflow

[nazar-pc]

I tried this code:

(0u16..).take(2usize.pow(16)).count();

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=618acba103fffa032a5bd07e870ef507

I expected to see this happen: Should result in 2^16 elements from 0u16 to 2^16 - 1 iterated over.

Instead, this happened:

thread 'main' panicked at 'attempt to add with overflow', /rustc/0599b6b931816ab46ab79072189075f543931cbd/library/core/src/iter/range.rs:397:1

Which doesn't make sense to me, it should have strictly limited itself to taking 2^16 elements and not a single more.

Meta

rustc --version --verbose:

rustc 1.70.0-nightly (0599b6b93 2023-04-01)
binary: rustc
commit-hash: 0599b6b931816ab46ab79072189075f543931cbd
commit-date: 2023-04-01
host: x86_64-unknown-linux-gnu
release: 1.70.0-nightly
LLVM version: 16.0.0

Also happens on latest nightly as of today and stable too.

Backtrace

thread 'main' panicked at 'attempt to add with overflow', /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library/core/src/iter/range.rs:397:1
stack backtrace:
   0: rust_begin_unwind
             at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library/std/src/panicking.rs:577:5
   1: core::panicking::panic_fmt
             at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library/core/src/panicking.rs:67:14
   2: core::panicking::panic
             at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library/core/src/panicking.rs:117:5
   3: <u16 as core::iter::range::Step>::forward
             at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library/core/src/iter/range.rs:209:25
   4: core::iter::range::<impl core::iter::traits::iterator::Iterator for core::ops::range::RangeFrom<A>>::next
             at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library/core/src/iter/range.rs:876:17
   5: core::iter::traits::iterator::Iterator::try_fold
             at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library/core/src/iter/traits/iterator.rs:2309:29
   6: <core::iter::adapters::take::Take<I> as core::iter::traits::iterator::Iterator>::try_fold
             at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library/core/src/iter/adapters/take.rs:97:13
   7: <core::iter::adapters::take::Take<I> as core::iter::traits::iterator::Iterator>::fold
             at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library/core/src/iter/mod.rs:372:13
   8: core::iter::traits::iterator::Iterator::count
             at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library/core/src/iter/traits/iterator.rs:268:9
   9: playground::main
             at ./[src/main.rs:2](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021#):5
  10: core::ops::function::FnOnce::call_once
             at /rustc/3a8a131e9509c478ece1c58fe0ea2d49463d2300/library/core/src/ops/function.rs:250:5

[cuviper]

The documentation of RangeFrom mentions this:

Note also that overflow happens earlier than you might assume: the overflow happens in the call to next that yields the maximum value, as the range must be set to a state to yield the next value.

For example, even (u16::MAX..).next() will panic.

[nazar-pc]

Interesting. Glad that it is documented, but it is certainly unexpected behavior and not caught by compiler/clippy.
Interestingly, (0..=u16::MAX).count() doesn't have this issue.

[cuviper]

Yes, RangeInclusive deliberately supports end == MAX -- otherwise you could just use Range with end + 1.

[kadiwa4]

I think it's actually quite intuitive why this wouldn't work.
Consider this edited version of your example:

let mut iter = 0u16..;
(&mut iter).take(2usize.pow(16)).count();
dbg!(iter);

What state would you imagine the iterator ends up in?
u16::MAX would certainly be unexpected because that's already been yielded by next in the line above.

Of course a compiler warning would be nice but I don't see how you could generalise this. Do you have a real-world example of how you could run into this issue?

[nazar-pc]

I see logic behind what you wrote. And yes, I did run into this issue, hence bug report (in one case I almost literally used provided example code, in another I was doing .zip()ping with iterator of at most 2.pow(16) length, which triggered the same issue).

Iterator implementation for such range certainly could have not advanced forward unless next() is called to avoid this issue. Then nothing would have to panic.

Implementation would be something like this:

fn next(&mut self) -> Option<Self::Item> {
    // Do not advance on the very first `.next()` call
    if !self.started {
        self.started = true;
    } else {
        self.last_value += 1;
    }

    return Some(self.last_value);
}