[bpicolo]

> Inclusive ranges are especially useful if you want to iterate over every possible value in a range

Out of curiosity, why was the (or an alternative) choice not to make the compiler understand that the 0..256 was not inclusive, and somehow correct the literal value to do what's intended? Would that have been unusually complicated or?

Edit: Overall, still an amazing release, this was just the bit I'm curious about :) Great work by the whole Rust team/community

[steveklabnik]

Every language I’m aware of has different syntax for inclusive vs exclusive range; making it situational would be quite confusing, I’d imagine.

[Animats]

Go deliberately left that out.[1] Probably a good decision.

[1] https://groups.google.com/forum/#!msg/golang-nuts/7J8FY07dkW...

[pjmlp]

Go left almost everything out.

[mohn]

Huh, given the context of loop ranges over integers, when I saw the EWD link in that thread, I guessed it would be the "Why numbering should start at zero" one. Instead, the one linked ("On the cruelty of really teaching computing science") is about 10x longer, and it was an interesting glimpse into his philosophy.

[bpicolo]

Definitely agree that having the inclusive syntax makes sense either way (..= was mildly jarring at first but makes complete sense syntactically) - I just mean the exclusive ranges arriving at that compiler error definitely seems unexpected

[steveklabnik]

Ah! Yeah, I mean maybe. At the same time, special cases can make things harder to understand. This would also technically be a breaking change, though probably not changing any realistic programs.

[GolDDranks]

There is actually a simple reason for that: the ranges might not be constant literals. So the end value must be an expression of some type; here u8. u8 can hold only values 0-255; 256 is out if its range.