3 ms·

The same way switch works in every language and regardless of the clever pattern: find the first expression that equals and jump to that label.

int_19h 6y ago
A better question is: which "case" expressions are evaluated - all of them, or only the ones enumerated before the match was found? Unless you use this pattern regularly - and most coders don't, even those who mostly write JS - you'll probably have to look the answer up. That alone is a good reason to stick to if/else; there's no such ambiguity there.
- lifthrasiir 6y ago
  > A better question is: which "case" expressions are evaluated - all of them, or only the ones enumerated before the match was found? Good point. By the way the answer is the latter, so the following prints 1 and 2. switch (true) { case (console.log(1), false): case (console.log(2), true): case (console.log(3), false): break; }
  - Kinrany 6y ago
    Easy enough to remember because this is the simplest thing the language can do, but yeah, I have no idea if this is the same between popular languages.
    - int_19h 6y ago
      In the non-Boolean case, a common implementation technique for a large switch with sequential values is a jump table. But that's only possible when all case labels are known.
- gbear0 6y ago
  The other ambiguity that I questioned right away was whether the language itself guarantees the order or evaluation or if it's compiler dependent? If I switch between Chrome & Firefox would I get different results? Also, by using non const expressions in case statements you lose the ability to have a large number of cases get mapped into a jump table. Although, I don't even know if more modern languages even support this optimization anymore since I think supporting non const case expressions is becoming the norm in a lot of languages.
  - sfink 6y ago
    JS is specced up the wazoo, including the exact execution semantics. It's fairly difficult to write JS that executes differently between Chrome & Firefox. The only things with intentional nondeterminism in the core language are WeakRef and FinalizationRegistry. And those won't just behave differently between browsers, they may behave differently across browser versions, loads, user activity, etc. Date parsing has different edge cases between browsers. The DOM obviously provides more nondeterminism as well as deterministically different behavior, and there are some different things exposed to web pages so it's not like you can't detect which engine you're running on. But things like exact switch case execution ordering are well-covered by the spec.
- Kinrany 6y ago
  Good point, using non-pure functions would be confusing.
mlyle 6y ago
But in many languages, the cases need to be compile-time constant rvalues.
tsimionescu 6y ago
Many languages don't allow duplicate values for case in switch statements, so that question never comes up - this is true for C, C++, C#, Java. Go, Ruby do behave like JS here.

int_19h 6y ago

A better question is: which "case" expressions are evaluated - all of them, or only the ones enumerated before the match was found? Unless you use this pattern regularly - and most coders don't, even those who mostly write JS - you'll probably have to look the answer up. That alone is a good reason to stick to if/else; there's no such ambiguity there.

lifthrasiir 6y ago
> A better question is: which "case" expressions are evaluated - all of them, or only the ones enumerated before the match was found? Good point. By the way the answer is the latter, so the following prints 1 and 2. switch (true) { case (console.log(1), false): case (console.log(2), true): case (console.log(3), false): break; }
- Kinrany 6y ago
  Easy enough to remember because this is the simplest thing the language can do, but yeah, I have no idea if this is the same between popular languages.
  - int_19h 6y ago
    In the non-Boolean case, a common implementation technique for a large switch with sequential values is a jump table. But that's only possible when all case labels are known.
gbear0 6y ago
The other ambiguity that I questioned right away was whether the language itself guarantees the order or evaluation or if it's compiler dependent? If I switch between Chrome & Firefox would I get different results? Also, by using non const expressions in case statements you lose the ability to have a large number of cases get mapped into a jump table. Although, I don't even know if more modern languages even support this optimization anymore since I think supporting non const case expressions is becoming the norm in a lot of languages.
- sfink 6y ago
  JS is specced up the wazoo, including the exact execution semantics. It's fairly difficult to write JS that executes differently between Chrome & Firefox. The only things with intentional nondeterminism in the core language are WeakRef and FinalizationRegistry. And those won't just behave differently between browsers, they may behave differently across browser versions, loads, user activity, etc. Date parsing has different edge cases between browsers. The DOM obviously provides more nondeterminism as well as deterministically different behavior, and there are some different things exposed to web pages so it's not like you can't detect which engine you're running on. But things like exact switch case execution ordering are well-covered by the spec.
Kinrany 6y ago
Good point, using non-pure functions would be confusing.

mlyle 6y ago

But in many languages, the cases need to be compile-time constant rvalues.

tsimionescu 6y ago

Many languages don't allow duplicate values for case in switch statements, so that question never comes up - this is true for C, C++, C#, Java. Go, Ruby do behave like JS here.