I think there's an argument to be made that switch statements already do something adjacent to pattern matching. At the least, it's close enough that something like:
switch(expr) {
case 'foo':
break;
case { foo: bar }:
break;
}
Wouldn't strike me as all that strange. It just shifts the semantics from "are you exactly this" to "do you look like this". For non-object primitives (e.g. string or number), I don't think those two things are functionally different.
Granted, it doesn't help make switch any easier to learn, but I _do_ think it makes switch more _rewarding_ to learn. Right now, switch is basically just a restrictive, potentially terser version of an if statement. This would make switch actually useful to learn.
It might even allow us to add some more semantics to switch over time (e.g. constructor matching with something like 'case Number').
(EDIT: thanks to armandososa for teaching me a new thing!)
I'd argue we should strive to move away from the switch syntax where it's not necessary because it's verbose and has curious semantics [1]. As an example, this should work:
switch(expr) {
case 'foo':
console.log("a string")
break;
case { foo: bar }:
console.log("foo is", bar)
break;
}
But how would this work?
switch(expr) {
case 'foo':
case { foo: bar }:
console.log("foo is", bar)
break;
}
Moreover, a big selling point of pattern matching is it is an expression. Keep in mind though case points to a statement list, How do we resolve to a value?
With a "return"?
function f() {
switch(expr) {
case 'foo':
return 4 // This makes f return
}
}
function g() {
var x = switch(expr) {
case 'foo':
return 4 // But this doesn't. Is this confusing?
}
}
The value of the last statement?
function g() {
var x = switch(expr) {
case 'foo':
4; // This should resolve to 4
break; // but is the break necessary now?
}
}
IMO switch sytnax is just legacy left behind by C, and not the best one to keep around, especially given the semantics of pattern matching.
C's switch/case is essentially a special case with a limited set of values (literals) and no destructuring. You can extend it to less trivial patterns and blam pattern matching.
No, switch is not like a special case of match. C's switch is a kind of computed goto and can build irreducible control flow graphs. match is a reducible structured control-flow construct whose power comes from destructuring. match is much, much more like an if-else chain than a switch.
var x = match (response) {
case { status:200 }: true;
case { status: 404 }: new NotFoundError;
case Number: Math.PI;
case SomeClass: 1;
case /^http/: "http error";
default: -1;
};
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...)
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.
> [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.
I think an example would resemble how Swift integrated pattern matching into their regular switch statements, it doesn't require too much creativity to envision.
I think match cases should be functions, since you have built those anyway.
So instead of match (x) { expr... } you would have something like
match(x, [ fn... ]) or
match(x) { name: fn, name2: fn2 }
where fn is like (objectToMatch) => { expr }
No. That would make the actual switch statement a value, rather than make switches expressions. And your version is completely different as you make cases into guards rather than labels or patterns.
This would introduce a weird inconsistency with cases for match and cases for switch regarding fallthrough, though. If it's going to look like cases in a switch statement, it should act like them, for better or worse.