# `...` vs `..=` for inclusive ranges

#88

That’s not a convention that was ever used when I studied my maths BSc, but I’ll take your word for it.

#89

Let me clarify: I am not saying that it is a commonly used convention, of course in a math course you would for instance study function y = 1/x with x in interval (0, 10]. However, numerical methods such as finite difference rely on discretization, so `(0.0>..10).step_by(0.001)` would be a convenient way for discretization of the continuous interval (0, 10]. In my posts above I wanted to provide some use case examples of notation `...`, `..<`, `>..`, `>.<`, to explain why IMO they would be useful when dealing with floats. The primary use would be as patterns in `match` and `if` expressions. The secondary use would be for definition of ranges.

#90

Let me clarify: there is nothing wrong with half-open ranges, but a function like `step_by` is going to have to make some arbitrary choices. (Even with closed ranges; for example what does `[0...10].step_by(3)` yield? Don’t answer that; I have a habit of writing rhetorical questions.)

But all that is besides the point. Whatever arguments you make, a feature is only ever going to be adopted if the right people are personally convinced that usefulness outweighs cost in real world usage (which doesn’t include contrived examples).

I don’t count as one of the “right people” BTW (nor do I want to), so stop trying to convince me.

#91

Sorry to dredge this up if there has already been some resolution which i didn’t see, but…

How about `,,` for inclusive ranges? The comma looks like a period with a tail, so `,,` could be thought of as being like `..` but with the tail element. Also (e.g.) `1,,10` looks like a shortened form of a mathematics-style 1, 2, …, 10.

Separately (and particularly when it comes to matching and floats), i would like like to see the syntax proposed by ecnahc515 (`[1..10)` etc) allowed. I realize it would be a big change, but the parens are balanced if you allow them to be matched with the brackets. I guess in this case `a..b` would be a shortcut form of `[a..b)`, and `a,,b` would be a shortened form of `[a..b]`.

#92

RFC 1192 was accepted a week ago. The `...` syntax will be used

#93

They accepted it? Funny, I expect lots of newbies making an off by one dot errors.

#94

IMO, the difference between two and three dot is obvious with monospaced fonts. And every text editor I know use monospaced font.

Every other proposal I saw seemed unnatural.

#95

### Math

exclusive: `[a..b)`, inclusive: `[a..b]`

exclusive: `<none>`, inclusive: `a..b`

### Elixir

exclusive: `<none>`, inclusive: `a..b`

### Ruby

exclusive: `a...b`, inclusive: `a..b`

### Swift

exclusive: `a..<b`, inclusive: `a...b`

### Rust

exclusive: `a..b`, inclusive: `a...b`

Language designers be trolling. ¯\_(ツ)_/¯

#96

Math exclusive: [a…b), inclusive: [a…b]

Where I am, in math the exclusive is written:

[a … b[

#97

Both is valid.

#98

Here’s an idea for the syntax, straight from base math textbook:

``````0 <= .. <= 5	// inclusive, [0,1,2,3,4,5], same as ...
0 <= .. < 5	  // left inclusive, [0,1,2,3,4], same as ..
0 < .. <= 5  // right inclusive, [1,2,3,4,5]
0 < .. < 5  // exclusive, [0,1,2,3,4,5]

1 < .. < 1 // []
1 <= .. < 1 // []
1 <= .. <= 1 // [1]
2 <= .. <= 1 // []
``````
``````a..b
a...b
``````

becomes sugar for

``````a<= .. < b
a<= .. <= b
``````

Good thing, it can be used the other way round for range constructors where the bounds are reversed (a >= b).

``````for i in 5 >= .. >= 0    // [5,4,3,2,1,0]
for i in 5 > .. >= 0    // [4,3,2,1,0]
for i in 5 >= .. > 0    // [5,4,3,2,1]
for i in 5 > .. > 0    // [4,3,2,1]
``````
• Reuses existing operators
• Always read as “math”, easy to figure out for outsiders
• Rust explicitness: both operators are mandatory, except when used in the “sugared” backwards compatible version
• Spacing/separation TBD (but not ambiguous)
• Looks like an extension of the existing syntax
• No problems with open/close bracket rules

#99

That’s ambiguous as `..` is already a valid range. Rust would parse that as `0 <= RangeFull <= 5`.

#100

Not necessarily. That would depend on the grammar.

Is 0 <= RangeFull <= 5 a valid construct?

#101

You’re right, rust (probably) wouldn’t accept that as chained comparisons need parentheses.

However, personally, I’d find it quite confusing. When I see number - space - comparison operator, I assume I’m looking at a comparison.

#102

Fair enough. It depends on how used you are to stuff like say “0 ≤ x < 5”. I find it quite clear and straightforward. I do like the

``````[0, 5)
``````

Notation quite a lot, but I’m sure if we adopted it it would wreak havoc in all existing editors, formatters and color highlighters.

#103

``````for 5 < i <= 10
for 5<= i < 10

or the other way around

for 10 > i >= 0
for 10 >= i > 0
``````

and so on?

#104

I like this but it’s ambiguous outside a for loop. How would you declare a range?

``````let range = 5 < i <= 10; // what is i for?
for item in range { ... }
for item in (10 > i > 0) { ... } // what is i?
``````

perhaps

``````for item in (10 > _ > 0) { ... }
``````

would do?

#105

Well I like the idea for ranges

``````let range2 = 10  > .. >= 6
``````

so

``````let range1 = 5 <= .. < 16
``````

is desugar for

``````let range1 = 5..16
``````

but I still think that this separation in for is nice

``````for 10 > idx > 0 { ... }
``````

is clear as water, even

``````for idx in 10 > .. > 0 { ...}
``````

than instead (which doesnt work right now)

``````for idx in 9..-1 {
}
``````

you need to write some like

``````let r1 = 1..10;
for idx in r1.rev() {
println!("{:?}", idx);
}
``````

#106

It’d work in C++ (overload `operator <=(FullRange, T)` to return `RangeToInclusive<T>`), but `PartialOrd` says `<=` can only return bool, via `partial_cmp` returning `Option<Ordering>`, so I assume it can’t work in Rust. (And PartialOrd requires PartialEq, so it’d also allow silliness like `4 == .. == 2`.) I assume it’d be completely doable as a macro, though. Then you could even make `range!(0 <= r)` turn `RangeTo(5)` into `Range(0, 5)`.

Let me also plug the comment I posted on the other thread about ranges. TL/DR: From an algorithmic perspective, I think all `std` should provide is the Range [a,b) where b is ‘reachable’ from a by zero-or-more-but-finite applications of a successor function (aka, roughly, a ≤ b). Going beyond that feels like we’re making an interval library, which is a totally different thing, and the current range is no better than a pair.

closed #107

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.