The better solution to forgetting whether an interval is closed or half-open is to always use only half-open intervals, without any exceptions.

In most cases half-open intervals result in the simplest program, so I agree with the choice of Zig, which is inherited from other languages well-designed from this point of view, e.g. Icon.

I find half-open intervals more intuitive than either closed intervals or open intervals, and much less prone to errors, for various reasons, e.g. the size of a half-open interval is equal to the difference between its limits, unlike for closed intervals or open intervals. Also when accessing the points in the interval backwards or circularly, there are simplifications in comparison with closed intervals.

> always use only half-open intervals

That means you have to waste bytes for the index when you need to include ..._MAX.

By "..._MAX" I assume that you mean the maximum value of a given integer type.

In a language where half-open intervals are supported consistently in all the places, this would be solved trivially, e.g. for a signed byte the _MIN and the _MAX values would be defined as -128 and +128, more intuitively than when using closed intervals, where you must remember to subtract 1 from the negated minimum value.

Even the C language has some support for half-open intervals, because the index pointing after the last element of an array is a valid index value, not an out-of-range value (though obviously, attempting to access the array through that index value would be trapped as an out-of-range access, if that is enabled).

Applied consistently, the same method would ensure that the value immediately above the last representable value of an integer type is valid in ranges of that type, even if it would be invalid in an expression as an operand of that type.

Rust's solution to this is quite good, that's 0..9 and if you want to include 9 it's 0..=9, it looks a bit funny but knowing one with an = sign in it exists removes any doubt

Adding additional syntax to a language for this case seems bonkers to me. People can just write 0..10.

If you need `0..=n`, you can't write `0..(n+1)` because that addition might overflow.

I'm actually curious now how this is stored on `Range` in rust. I've certainly used ..= for exactly the reason you say, but as far as I'm aware `.end` on the range is the exclusive upper bound in all cases. What happens to `.end` in the overflowing case?

Edit: it doesn't use Range for ..=, but rather RangeInclusive, which works fine.

It's more meant for usage with variables:

  for i in 0..length {
    …
  }

  for i in 0..=maxindex {
    …
  }

I completely agree. One of Zig's big competitors, Odin, has a more explicit syntax for this where `0..<5` is an open interval and `0...5` is closed.

I think that comes from Ruby, right? I know Groovy is inspired by Ruby and has exactly the same syntax.

EDIT: oh just noticed it's 3 dots in the close case... in Groovy it's just 2.

Odin's even better than that—you can only use `0..<5` and `0..=5`, so there's never any ambiguity whatsoever.

I even forget which word means what, "open", "close"

> an open interval [0..9)

See Dijkstra for why this is the right way to represent ranges: https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831...