syntax for case ranges

# Sultan (23 days ago)

For example, the following:

switch (value) { case 0...9: break case 'a'...'z': break }

# Felipe Nascimento de Moura (23 days 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.

[ ]s

--

Felipe N. Moura Web Developer, Google Developer Expert developers.google.com/experts/people/felipe-moura, Founder of

BrazilJS braziljs.org, Nasc nasc.io and On2 on2.dev.

Website: felipenmoura.com / nasc.io Twitter: @felipenmoura twitter.com/felipenmoura

Facebook: fb.com/felipenmoura LinkedIn: goo.gl/qGmq

  • Changing the world* is the least I expect from myself!
# Oriol _ (23 days ago)

This sounds like tc39/proposal-pattern-matching

El 31/1/20 a les 10:57, Sultan ha escrit: For example, the following:

switch (value) { case 0...9: break case 'a'...'z': break }

# Bruno Macabeus (23 days 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 (23 days 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 (23 days 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 (22 days 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 (22 days ago)

3 < 2 < 1; // true

# Naveen Chawla (20 days 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 (20 days 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 (20 days 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 (20 days 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 (20 days 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 (20 days 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 (20 days 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 days 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.