ops::Range::end out of range (overflowing_literals)

[hellow554]

I would expect that the the following prints would lead to the same result, instead rust complains about 256 being out of range for u8, which is correct, but because end is exclusive, it should't complain.

#![feature(inclusive_range_syntax)]

fn main() {
    let range_a = 0..256;
    let range_b = 0..=255;
    
    println!("{:?}", range_a.collect::<Vec<u8>>());
    println!("{:?}", range_b.collect::<Vec<u8>>());
}

PlayGround

[hellow554]

Okay, after thinking about this issue and talking with somebody this is very, very difficult to solve.
Range uses the underlying type (in this case it is an u8) and so it complains about being out of range (256 does not fit into a u8, period!)
In this case (aloso for u16, i16, u32, ...) it should work, yes, but range is defined for a type that implements PartialOrd and not only numeric literals which is indeed a problem.
The question, is this anyhow solveable?
If somebody stumbles across this, I'd like to hear his/her comment, but would also accept a comment closed #Notabug :)

[leonardo-m]

The solution is to use 0 ..= 255 to denote a closed interval. That syntax was invented to solve the problem you note.

[durka]

This is the entire reason that inclusive ranges were added.

[durka]

Actually -- perhaps keep this open as a diagnostics issue? Is it possible for overflowing_literals to have a note recommending an inclusive range? Sorry for my dismissive tone in the previous comment.

[porglezomp]

I'd like to try working on this issue.

[porglezomp]

How does this look for a possible message?

warning: literal out of range for u8
  --> $DIR/suggestions.rs:61:23
   |
LL |         for _ in 0u8..256 { }
   |                  -----^^^
   |                  |
   |                  help: use a closed range: `0u8..=255`
   |
   = note: #[warn(overflowing_literals)] on by default

[leonardo-m]

That message seems nice.

[hellow554]

Closed or inclusive range? The feature was named inclusive, that's why I'm asking.
Also, can you please verify, that the note will not appear with 257? 😅 Would be a classic that I would forget to Check

[porglezomp]

You're right, that should say "inclusive." I should also handle ..256u8 -> ..=255u8, even though that's probably a much less common case.