range(a, b) does not work when a > b

[jesseray]

This code works:

fn main() {
    for i in range(0, 256) {
        println(i.to_str());
    }
}

but this code doesn't:

fn main() {
    for i in range(255, -1) {
        println(i.to_str());
    }
}

The compiler shows no warnings or errors and the executable produces no output:

[jesse@localhost ~]$ rustc nums.rs
[jesse@localhost ~]$ ./nums
[jesse@localhost ~]$ 

It seems to me that range(a, b) should work for both cases, a < b and a > b.

[thestinger]

It's not intended to yield anything when the start isn't less than the stop parameter. You can use range_step(start, stop, -1) or take advantage of it being a double-ended iterator and use invert.

[thestinger]

Tagging as an RFC.

[adrientetar]

I think Python doesn't support negative looping without additional parameters or func but I guess that supporting that "natively" would make sense.

[huonw]

I'd be pretty strongly against this: I imagine it'd be a source of bugs and confusion when range(i, j) sometimes iterates i, i - 1, ... and requires awkward special casing by user-code to avoid, rather than the C/C++/Python constructs which won't magically change direction.

(R does the backwards enumeration automatically, and it can be very annoying, requiring ugly ifs and so on to actually make things work correctly. (Admittedly this isn't the worst part of R, or even just R's vectors.))

[adrientetar]

You have a point. Plus there are already the two methods mentioned by thestinger which aren't heavy on the code part (the actual loop mechanism is just like Python right now), so I would be favor of closing this.

[klutzy]

The suggestion seems too magical. I'm with @huonw; R injured me several times.

[jesseray]

I think range(a, b) where a > b should work. It seems strange to write extra code for steps (range_step), inversions (invert), or mutable variables (i = i - 1) just to make a basic countdown. Countdowns seem common enough that a programming language should provide a succinct way to make them. In any event, these other solutions work well enough, so I'm not going to press the point.

With that said, I still think that some change ought to be made. If my suggestion is not implemented, then range() should probably be changed so that the programmer is informed that the function is not meant to be used that way. As it stands, the function feels incomplete, perhaps buggy, because it gives no return value, no compilation error, no runtime error, no warning, no suggestion, no nothing. Functions should be black boxes, not black holes =P.

[thestinger]

@jesseray: The documentation already says it iterates over [start, stop) and it can be expanded if it's not clear it means an ascending range.

[jesseray]

The source of my confusion has become clear.

When you sit in the pub with a friend and hear them say "the people I have dated range from skinny to fat" or "the people I have dated range from fat to skinny", you would understand both statements as referring to the same group of people, just put in a different order. This is the plain language sense of the term "range" and that is how I tried to understand range().

Consider the two code examples at the top of this issue. The intention was to loop through every possible value that an unsigned byte could have: 0 to 255. Because I had the plain language "range" in mind, my first attempt at writing the code was for i in range(0, 255), which I thought would be equivalent to for i in range(255, 0). If range() worked as I expected, both codes would have worked without flaw.

That code did not work. From the output, the needed change was obvious: for i in range(0, 256), which I thought would be equivalent to for i in range(255, -1). This seemed strange, because 256 and -1 were not possible values for an unsigned byte. The code looked convoluted and ugly, but it seemed to work. For some reason or another, I decided to rewrite the code to what I thought was its equivalent for i in range(255, -1) and found that it did not work at all: no output, no error, no warning, no nothing. That compounded the ugliness.

Knowing that range() indicates a half-closed interval dispels my earlier confusion about the values to use as parameters, but still seems convoluted and ugly. Why have a function for half-closed intervals, but not plain language ranges? Why have a tutorial that teaches people to use half-closed intervals for loops when such loops cannot do everything programmers want? Why are half-closed intervals called ranges instead of intervals? And why does it ask for a half-closed interval, instead of a completely closed interval? (I am here referring back to the semantics issue.) These decisions are all kind of weird.

Can we reach a compromise? The most straight-forward solution would be renaming range() to interval() and perhaps reworking the code so it uses completely closed intervals, and then write a new range() that captures the plain language sense of the term. This solution would be the most straight-forward, but it could be disorienting for the current users of Rust, so perhaps another solution would be better?

[thestinger]

Rust uses 0-indexed arrays and the range function is a good fit for that since you can give the length directly as the end parameter without needing to subtract one and handle underflow for 0-length arrays. This is the same definition used by range in Python, irange in Boost, and iota in D. There's a range_inclusive function for inclusive ranges.

I don't think it's worth changing the default, because it's already the most familiar definition for those coming from other languages with 0-indexed arrays.

[pnkfelix]

see also #1817 , some discussion of range_rev on #4313, and discussion of the semantics for range_rev on #5270, namely about what kind of half-open interval it should represent.

(Of course the range_rev internal iterator routine went away with the shift to external-iterators; but I thought some of the discussion on those tickets was relevant, e.g. about whether to make reverse iteration a separate function or to infer the step from the arguments. )

In my opinion inferring the step from the arguments would be a bad move, at least for our half-open intervals. (It would be easier to accept for range_inclusive, except that then range_inclusive would deviate from range in more ways than one would expect.

I think we should close this ticket as not-a-bug. As @thestinger said, the precedent for the method name range has been established, and one can use the invert method to switch the direction of the iteration to get the effect of range_rev.

[42f87d89]

Forgive me for commenting in such an old issue, but I feel that this must be adressed.

In the current release of Rust, (a..b), where a > b, has the same behaviour as what was described in the issue. It simply does nothing.

How is silently failing a valid outcome of something in a language designed to prevent errors? If (a..b), where a > b, is not valid input, the language should be explicit about it. Either a compile-time error, or a panic.

[thestinger]

It's a perfectly valid input. The range is just empty.

[alexispurslane]

@42f87d89 I totally agree.