A problem with that is that, in JavaScript, case clauses in switch statements fall through to the next clause, whereas they shouldn’t in match statements.

When reading the code, that means you need to hunt for the match or switch statement to know what happens at the end of a case clause.

IMO, if one is willing to correct historical errors, even if they are engrained, Apple’s Swift language makes the best choice here. It requires an explicit fallthrough to fall through to the following case, and goes even further than what you propose by only having a switch keyword (https://developer.apple.com/library/content/documentation/Sw...)

I like it, especially `default` instead of `{}`

The leading curly braces in the linked proposal _are_ a bit odd to see, though the repetition of `case` isn't too fun either.

Braces can be used in many cases, but `case` keyword is used only in `switch` and `match` and is not ambigious. You can see what construct it is from the first word.

I suspect the example in the proposal refers to an object that doesn't match any of the previous options, but is still an object.

For a default I'd expect there to be another pattern.

The default pattern is a variable name.

> [About variable name patterns binding to the name] Eliminates the need for an else/default leg, because assignment to any variable will be sufficient. JS programmers are already used to assigning variables that are then ignored (in functions, in particular), and different people have different tastes in what that should be. _, other, etc, would all be perfectly cromulent alternatives.

I don't like it. This is a false consistency. It looks like a switch but works totally differently (match is semantically more like an if-else chain). The proposal author gives a similar rejection of this syntax under the section "=> for leg bodies" in the proposal.