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

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

**lucatrv**#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.

**dhardy**#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.

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]`

.

**Uther**#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.

**regexident**#95

### Math

exclusive: `[a..b)`

, inclusive: `[a..b]`

### Haskell

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. ¯\_(ツ)_/¯

**leonardo**#96

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

Where I am, in math the exclusive is written:

[a … b[

**norru**#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

**stebalien**#99

That’s ambiguous as `..`

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

.

**norru**#100

Not necessarily. That would depend on the grammar.

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

**stebalien**#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.

**norru**#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.

**tyoc213**#103

how about

```
for 5 < i <= 10
for 5<= i < 10
or the other way around
for 10 > i >= 0
for 10 >= i > 0
```

and so on?

**norru**#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?

**tyoc213**#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);
}
```

**scottmcm**#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.

**nikomatsakis**closed #107

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