New Issue: Should maximal ranges be considered empty ranges? / Should ranges default to 0..-1?

17605, "bradcray", "Should maximal ranges be considered empty ranges? / Should ranges default to 0..-1?", "2021-04-27T16:20:09Z"

Typically, empty ranges have been represented in Chapel as the value 1..0 by default, on the basis that every index type with at least two values can represent it. Another compelling empty range value to consider is 0..-1, which has some modest attractive qualities:

  • it can be thought of as being similar to the range 0..<0 which today amounts to 0..-1 and which feels appropriately default-y compared to, say, 1..<1 (arguably what we have today)
  • it keeps the default low bound of the range 0, as it would be in other "implicit indices" cases (and for some reason, making the low bound 0 seems to appeal more than having the high bound be 0).
  • related: for index types with only a single value (like single-value enums), the low bound is representable in the index type (which, again, somehow appeals more than saying "the high bound is representable" today).

However, it also has a significant disadvantage, which is that unsigned integer types can't represent -1.

At the same time, we have significant problems or challenges with so-called "maximal" ranges (e.g., 0..max(uint(64)), such as: (a) their size can't be represented using their index type, (b) it's challenging to create iterators that work correctly for them while also being efficient for more typical ranges. These problems haven't been that problematic for us because maximal ranges don't come up very often in practice.

This combination of observations has led me to wonder whether maximal ranges (by some definition) ought to be considered an alternate form of empty range; and whether the default range value should be represented as 0..(-1):idxType.

I don't think there's anything deeply pressing here, but I wanted to capture the notion for reference and possible discussion.