I didn't realize how rich the normal match { } patterns can get until I saw these matches!() examples and was trying to figure out what that pattern syntax was. I've only ever used the basic enum matching/enum value unwrapping patterns.

I'm actually planning on declaring war against pattern matching in EcmaScript, which is stage 1 right now. I can't believe how popular it can be. To me it looks like a huge antipattern, a complete different way of writing conditionals from ifs, built in a way that can lead to completely unreadable code (for complex matching) and very inconsistent behaviour. And just like switch-case, become something to avoid outside of byte-sized or plain literal matching.

Not to mention how much each language differs in how the syntax and behavior is implemented, making it harder for beginners everywhere to ramp up.

Like the smart-match clusterf* in Perl, pattern matching is just too darn clever for its own good.

Rust’s pattern matching is deliberately fairly limited in what it can do; it’s all about destructuring types, not running arbitrary code like Perl’s smart-match (which even so I would not describe as a disaster). It’s conceptually very clean—arguably simpler than what ECMAScript already has. `let PATTERN = EXPRESSION;`, `if let PATTERN { … }`, `match EXPRESSION { PATTERN => … }`, `fn NAME(PATTERN: TYPE)`, &c., everything that can introduce a new binding is a pattern. Some of the uses of patterns are refutable (match branches, `if let`, `while let`), and some irrefutable (`let`, `for`, function arguments, closure arguments).

ECMAScript already has destructuring in various places, corresponding to irrefutable pattern matching; what the proposal’s `case` expression introduces is essentially just refutable destructuring, plus a smidgeon of expression-orientation (`->` corresponding to `=>`, that `case` is an expression that yields a value, rather than a statement) in a place that sorely needs it. This is a very logical extension of the language.

If TC39 or equivalent were to design a new language to actively replace JavaScript (meaning something that all extant JavaScript code should be able to migrate to easily, preferably automatedly), there is no doubt in my mind that the language would be more expression-oriented than ECMAScript is, that destructuring syntax would be brought in line with what we call pattern matching so that there was one coherent concept underneath (probably called pattern matching), and that `switch` would use it, becoming equivalent to this proposal.

The way people use JavaScript these days, these things are useful.

(I write all this as an expert and heavy user of both Rust and JavaScript; I use JavaScript more, most of the time, but prefer Rust. Rust was the first language I learned with each of algebraic data types, pattern matching and expression orientation.)