`char` open ended range isn't bounded by `char::MAX`

[ChrisDenton]

I tried this code:

for _ in '\0'.. {}

I expected to see this happen: Runs without error.

Instead, this happened:

thread 'main' panicked at 'overflow in `Step::forward`', /rustc/2a8221dbdfd180a2d56d4b0089f4f3952d8c2bcd\library\core\src\iter\range.rs:88:45

Meta

rustc --version --verbose:

rustc 1.71.0-nightly (2a8221dbd 2023-05-11)
binary: rustc
commit-hash: 2a8221dbdfd180a2d56d4b0089f4f3952d8c2bcd
commit-date: 2023-05-11
host: x86_64-pc-windows-msvc
release: 1.71.0-nightly
LLVM version: 16.0.2

Backtrace

   0: std::panicking::begin_panic_handler
             at /rustc/2a8221dbdfd180a2d56d4b0089f4f3952d8c2bcd/library\std\src\panicking.rs:578
   1: core::panicking::panic_fmt
             at /rustc/2a8221dbdfd180a2d56d4b0089f4f3952d8c2bcd/library\core\src\panicking.rs:67
   2: core::panicking::panic_display
             at /rustc/2a8221dbdfd180a2d56d4b0089f4f3952d8c2bcd/library\core\src\panicking.rs:150
   3: core::panicking::panic_str
             at /rustc/2a8221dbdfd180a2d56d4b0089f4f3952d8c2bcd/library\core\src\panicking.rs:134
   4: core::option::expect_failed
             at /rustc/2a8221dbdfd180a2d56d4b0089f4f3952d8c2bcd/library\core\src\option.rs:1932
   5: core::iter::range::Step::forward
   6: core::iter::range::<impl core::iter::traits::iterator::Iterator for core::ops::range::RangeFrom<A>>::next
   7: core::fmt::Arguments::new_v1
   8: core::ops::function::FnOnce::call_once

[compiler-errors]

Why is this char specific -- are any open-ended ranges bounded? This code also panics with overflow:

fn main() {
    for x in 0u8.. {
        println!("{x}");
    }
}

[ChrisDenton]

Because a char isn't an integer. It is a finite set, whatever the underlying representation may be. It even has a hole in the middle when represented as an integer.

[SkiFire13]

u8 is also not an integer but the finite set of numbers between 0 and 255 though

[joboet]

This is documented behaviour. Would it however be a breaking change to adjust the iterator implementation to stop on overflow? The current behaviour (panicking in debug and wrapping in release) is really unintuitive, and I can't imagine anyone relying on it, because it makes iteration over RangeFrom essentially useless.
Nevermind, that can't be implemented.

[ChrisDenton]

u8 is also not an integer but the finite set of numbers between 0 and 255 though

I think a char is materially different from a primitive integer. A u8 can only hold a subset of integers (and behaviour on overflow can be configured). A char can hold every single Unicode scalar value that can ever exist. It can't overflow because there's nothing else to... flow.