`...` 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 :smile:


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

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


#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

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?


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