... are both clear in their own ways.
..= is clear in that it obviously includes the upper bound, but it’s unclear in that it’s not obviously a range at all (it looks a lot like an augmented assignment operator to me—perhaps
a ..= b is equivalent to
a = a..b ).
... is clear in that it’s obviously a range (it looks very similar to
..), but it’s unclear in that it, well, looks very similar to
I personally prefer
... mostly because it looks a lot nicer, but also because it’s obviously related to
.. and doesn’t look like an assignment of some sort. Although I am concerned that
... would be hard to distinguish, I feel that there are only a few places where you really need to care about the distinction:
- When writing code. I don’t think the particular range syntax would matter for this, except for the rare case of typos (which I consider unlikely).
- When debugging code that you suspect has a bug caused by an off-by-one error. When doing this you’re likely to be looking very closely for the distinction between inclusive and exclusive ranges anyway, and so I don’t think the range syntax would make much of a difference here.
When reading code normally, I don’t think the distinction between inclusive and exclusive ranges is one that would be particularly important. Assuming the code is free of bugs, a range between characters is probably going to be inclusive, a range between
0 and something called
len is probably going to be exclusive, etc..
That means that (in my opinion) the only place where the range syntax really matters (apart from aesthetics) is in learning the language. I can imagine it being frustrating to remember which syntax does what, but we do have a good mnemonic—‘more dots, more numbers’. Which is why I like
...—it just looks nicer, but in my opinion doesn’t have too many downsides.