Discuss
  • syntax for case ranges

syntax for case ranges

# Sultan (4 years ago)

For example, the following:

switch (value) {
    case 0...9: break
    case 'a'...'z': break
}
# Felipe Nascimento de Moura (4 years ago)

Very interesting.

Once I wanted (and would have used a lot) something like a switchMatch. It would work like this:

switchMatch(value) {
  case /\d+/: { ... }
  case /\s+/: { ... }
  case /.../: { ... }
  default: {
    console.log('Didn't match any of the options');
  }
}

Of course you can have a regex like (\d+)|(\s+)|... but it would be more readable and would allow situations like yours to be easily solved, read, thought and taught.

# Oriol _ (4 years ago)

This sounds like tc39/proposal-pattern-matching

# Bruno Macabeus (4 years ago)

I agree with Oriol. We already have the proposal pattern matching, that has a very similar effect. I think that is better to improve pattern matching proposal in order to be able to match using ranges (or at least check if it's good to do) instead of create a new proposal.

# Sultan (4 years ago)

The pattern matching proposal does not handles the mentioned case:

switch(type) { case 0...5: }

being the equivalent of

switch(type) { case 0: case 1: case 2: case 3: case 4: case 5: }
# Isiah Meadows (4 years ago)

Still better to discuss it there - it's highly related to your suggestion. And I'm pretty sure an issue already exists related to that.

# Naveen Chawla (4 years ago)

Certain languages allow the expression 0<x<5. Does anybody know if this would be syntactically possible in JavaScript? Of course this would only apply for "if"/"while" statements.

# Mark S. Miller (4 years ago)

3 < 2 < 1; // true

# Naveen Chawla (4 years ago)

I didn't understand your reply.

I think currently it would raise an error, because 1 < 2 < 3 is currently saying (probably) true < 3.

But a "new" syntax could possibly parse that as a "chain" of comparisons.

Would this be acceptable to introduce into JavaScript (just curious)?

I've probably missed your point entirely, because I saw a short message "3 < 2 < 1 //true", and I've assumed you meant it in reverse.

# Claude Pache (4 years ago)

Try typing 3 < 2 < 1 in the web console of your favourite browser, and see the result: it will evaluate to true. No, your browser isn’t buggy, it is just following blindly the semantics of <.

Modifying the meaning of 3 < 2 < 1 in order to make it evaluating to false is a BC break. Is it acceptable? Dunno.

# Isiah Meadows (4 years ago)

Does make me wonder if engines should start collecting statistics on how often it's used and how often that result differs from if a Python-style chained comparison was done instead.

# Naveen Chawla (4 years ago)

Thank you Claude! I did miss the point.

Have there ever been "BC" breaks introduced into the language before? If so, is there a sustainable standard for an "acceptable" one?

# kdex (4 years ago)

Yes, there have been numerous backwards-incompatible changes to the language over the years.

You can find a list of them in section E of the ECMAScript language standard. IIRC, that list is non-exhaustive.

# Mark S. Miller (4 years ago)

While correct, each case asked the browser makers to make a risky and costly bet. When the risk was low and the payoff high, they've been great at doing so. This one does not fall into the viable risk vs reward territory.

# Naveen Chawla (4 years ago)

Thanks! Although I think it is a value judgement about how much risk is worth how much reward, and which reward, so I wouldn't classify it as necessarily a complete set of criteria yet, but it is certainly in the right direction. And very interesting to me. Thank you.

# Jordan Harband (4 years ago)

@kdex (sorry i missed this; your message was in my spam folder) if you find a way that Annex E is non-exhaustive, please file an issue on the spec - I would like it to be exhaustive.