Better error message when `start` is bigger than the `end` in `for(start..end)`

[IntegratedQuantum]

Zig Version

0.11.0-dev.1711+dc1f50e50

Steps to Reproduce and Observed Output

In continuation of #14700

const std = @import("std");

pub fn main() void {
	var start: u32 = 1;
	var end: u32 = 0;
	for(start..end) |x| {
		std.log.info("{}", .{x});
	}
}

At the moment this produces an integer overflow error:

thread 2222 panic: integer overflow
/home/mint/Desktop/test.zig:6:6: 0x20b56c in main (test)
 for(start..end) |x| {
     ^

Expected Output

I expect the error to be equivalent to the one we get for slicing:

thread 2319 panic: start index 1 is larger than end index 0
/home/mint/Desktop/test.zig:7:11: 0x20b60f in main (test)
 for(slice[start..end]) |x| {
          ^

[nektro]

not seeing an open issue right now, but this would additionally be helped if the safety check was extended to say integer underflow instead of overflow when it went negative

[BanchouBoo]

Is there a reason why this has to be an error at all? I think it'd make perfect sense for this code to work. I understand why it isn't allowed for slices, but I don't see any reason to disallow people from doing a backwards range loop.

[rohlem]

@nektro From what I remember in std.math as well, the term "underflow" was used for "numbers of too small magnitude" (usually when floats are involved),
while "overflow" was used for too large magnitude; both positive and negative.
Although I guess we could distinguish "negative overflow" (or "overflow towards negative infinity" to be even more pedantic) to be more descriptive.

@BanchouBoo I don't remember whether it was explicitly mentioned, but one concern was inclusiveness/exclusiveness of the last element.
With 0-based indexing (as with slices), it's more common to include the first and exclude the last element, so 0..1 has 0 as the only element.
When iterating downwards, 1..0 the meaning is not quite as obvious; including the 0 seems more natural to most,
especially since otherwise you'd have to write 1..-1 to include 0.
I guess the most ergonomic reading would be to always include the lower bound and exclude the upper bound, regardless of position, but that wasn't currently included in the feature.

[kuon]

I agree that iterating in reverse can be a common use case, but reverse range are tricky for the reasons @rohlem mentioned.

I would prefer something like reverse for (0..10) {} that would iterate in reverse (9 -> 0), and would also work with slices. But that was frowned upon on discord so I didn't propose the idea.

[nektro]

presumably reverse for (0..) |_| {} would start at std.math.maxInt(T) then?

[kuon]

Or a compile error "cannot reverse unbound range".

[dbregman]

It is more useful if start>=end is a no-op.

e.g. in rust:
for i in 1..0 {
}

or C++
for(int i=1;i<0;++i) {
}

[IntegratedQuantum]

@dbregman

It is more useful if start>=end is a no-op.

I originally made an issue about that. Check out Andrew's comment there.

So far I have gathered that for loops were designed only for iterating over indexable types such as slices and arrays, where [1..0] is illegal.
The fact that for loops now allow iterating over ranges seems to be merely a by-product of the recent addition of multi-object for loops.