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

[stebalien]

Currently, you would write:

match run_experiment() {
    0.0...10.0 => Ok("class 1"), // 0, 10 inclusive
    10.0...20.0 => Ok("class 2"), // technically includes 10 but matching is in-order
    other if other > 0.0 => Ok("oversize"), // guard > 0
    _ => Err(some_error), // fallback
}

[lucatrv]

Wow… I guess you agree that is not very simple to read, IMO this would be much better:

match run_experiment() {
    20.0>.. => Ok("oversize"),
    10.0>.. => Ok("class 2"),
    0.0... => Ok("class 1"),
    _ => Err(some_error),
}

[dhardy]

Ok, I have a question relative to this discussion. Suppose I have a series of measurement real values, and I need to classify them. For values between 0 (included) to 10 (included) output “class 1”, for values between 10 (excluded) to 20 (included) output “class 2”, for values above 20 output “oversize”, for values below 0 emit an error. How do I program this in Rust using a match expression?

Personally, I’d be tempted to an if expression for something like that.

let v = run_experiment();
let result = if 0.0 <= v && v <= 10.0 {
    Ok("class 1")
...

[lucatrv]

In this case IMO it would be nice to write:

let v = run_experiment();
let result = if v in 0.0...10.0 {
    Ok("class 1")
...

[dhardy]

Personally I’d rather write:

let v = run_experiment();
let result = if 0.0 <= v <= 10.0 {
    Ok("class 1")
...

But ternary operators are just another layer of complexity. I can live with the language as-is.

[Gankro]

Of course this exact example doesn’t require a ternary at all:

let res = if v < 0 { Err } 
else if v <= 10 { Ok("class 1") }
else if v <= 20 { Ok ("class 2") }
else { Ok("oversize") };

or with more clever formatting:

let res = 
     if v <  0  { Err } 
else if v <= 10 { Ok("class 1") }
else if v <= 20 { Ok("class 2") }
else            { Ok("oversize") };

[lucatrv]

Well… mine was just a simple example, but there could be 10 or 50 classes, are you suggesting to chain 10 or 50 if/else expressions?

From the Rust book, Match section:

Often, a simple if/else isn’t enough, because you have more than two possible options. Also, conditions can get quite complex. Rust has a keyword, match, that allows you to replace complicated if/else groupings with something more powerful.

is this true only for integers and strings?

Finally, following your reasoning, one could also say that the match expression is unnecessary because it can always be replaced with a series if/else expressions.

[lucatrv]

Instead of ternary operators, personally I would prefer to use ranges because:

• They could be used both in if and match expressions (see examples above).
• They are IMO easier to read and probably less complex to manage.
• They would fit nicely with the current .. / ... notation.

Here is another example: to compute and plot function 1/x with x going from 0 (excluded) to 10 (included), it would be nice to write:

let x = (0.0>..10).step_by(0.001).collect::<Vec<_>>();
let y = x.iter().map(|x| 1.0 / x).collect::<Vec<_>>();

IMO notation ..., ..<, >.., >.< could nicely coexist with current .. / ... notation. The fact that .. and ..< would be equivalent may be acceptable (to avoid typing an additional character for the most common case), or otherwise .. could be deprecated in future.

[dhardy]

(0.0>…10).step_by(0.001)

What does this mean? Start at 0, but reject it since it is not greater than 0, thus use first value 0.001? Or add some infinitesimal, say 10^-9? I’ve never seen an open range used to derive a sequence of values before, but I guess it’s only the step_by function which is at fault here.

I have little against the proposed extension to range syntax (only that it’s an extra feature). Possibly you should open an RFC, though @Gankro can advise you better on this.

[lucatrv]

(0.0..<10).step_by(0.001) means all values from 0 to 10 equally spaced with increments of 0.001, with 0 included and 10 excluded. Reversely, (0.0>..10).step_by(0.001) means all values from 0 to 10 equally spaced with increments of 0.001, with 0 excluded and 10 included. The first value would be 0.001.

[dhardy]

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

[lucatrv]

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]

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.

[juxtaposition-rocks]

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

[jschievink]

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

[DanielFath]

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

[Uther]

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]

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]

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

Where I am, in math the exclusive is written:

[a … b[

[StefanoD]

Where I am, in math the exclusive is written:

[a … b[

Both is valid.