switch(expr) {
case 'foo':
break;
case { foo: bar }:
break;
}
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!)
switch(expr) {
case 'foo':
console.log("a string")
break;
case { foo: bar }:
console.log("foo is", bar)
break;
}
switch(expr) {
case 'foo':
case { foo: bar }:
console.log("foo is", bar)
break;
}
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?
}
}
function g() {
var x = switch(expr) {
case 'foo':
4; // This should resolve to 4
break; // but is the break necessary now?
}
}
[1]: https://en.wikipedia.org/wiki/Duff%27s_device, not sure if this works on JavaScript (I doubt it), but the point is the switch cases essentially work like "goto"s.
switch(expr) {
case 'foo': break;
case { foo: bar }: break;
}
Sure is. Or a degenerate one if you prefer.
> match is a reducible structured control-flow construct whose power comes from destructuring.
Match on sum types with no associated data and you have a switch.
> match is much, much more like an if-else chain than a switch.
Depends on what you're matching.
switch (x) {
case 0:
while (i < l) {
s *= i;
case 1:
i += 1;
}
}
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;
};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...)
The leading curly braces in the linked proposal _are_ a bit odd to see, though the repetition of `case` isn't too fun either.
For a default I'd expect there to be another pattern.
> [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.
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 }
var x = match (response) {
case { status:200 }: true;
case { status: 404 }: false;
case Number: 0;
case SomeClass: 1;
default: -1;
}; var x = (switch(true){
case response === { status: 200 }:
return true;
case response === { status: 404 }:
return false;
case response === Number:
return 0;
case response === SomeClass:
return 1;
default:
return -1;
});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.