4 ms·

> 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 n

> 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 8y ago
Every language I’m aware of has different syntax for inclusive vs exclusive range; making it situational would be quite confusing, I’d imagine.
- bpicolo 8y ago
  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 8y ago
    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.
- Animats 8y ago
  Go deliberately left that out.[1] Probably a good decision. [1] https://groups.google.com/forum/#!msg/golang-nuts/7J8FY07dkW0/goWaNVOkQU0J https://groups.google.com/forum/#!msg/golang-nuts/7J8FY07dkW...
  - pjmlp 8y ago
    Go left almost everything out.
  - mohn 8y ago
    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.
GolDDranks 8y ago
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.

steveklabnik 8y ago

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

bpicolo 8y ago
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 8y ago
  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.
Animats 8y ago
Go deliberately left that out.[1] Probably a good decision. [1] https://groups.google.com/forum/#!msg/golang-nuts/7J8FY07dkW0/goWaNVOkQU0J https://groups.google.com/forum/#!msg/golang-nuts/7J8FY07dkW...
- pjmlp 8y ago
  Go left almost everything out.
- mohn 8y ago
  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.

GolDDranks 8y ago

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.