At least for me, I feel I'd be using this a lot for the boring but common use case of checking for empty arrays and such:
const doSomethingToArr = arr => match (arr) {
[] => whatever,
[x] => whatever,
[x, ...xs] => whatever
}And it isn't four lines saved, but four lines times the number of uses in the entire code base.
Why would you believe that?
And if you do believe that why don't you use a code golfing language?
Should someone now have to point out to you that a million-line function is worse than a ten-line function for calculating fizzbuzz? Is that meaningful discourse in your book?
In general I believe that number of lines of code is correlated with number of bugs, but I would hesitate to say that it is proportional to. Going in with the explicit goal of reducing the number of lines could easily lead to more bugs, not less.
Having less lines can make extremely unreadable code. Readable code with an error is easy to fix, unreadable code is not.
At the very least the ambiguity of doing TWO things (matching AND destructuring) should not be allowed since it changes the outcome based on whether a value is a literal or a variable with the exact same literal assigned to it (at least that's how I understand it from reading the examples)
Additionally, this would be the first "native" way to do deep equality testing of objects. I can see it being abused to do simple one-off checks that could otherwise have been done more simply in an imperative way.
Do we really need to save the five lines of code at the cost of new syntax? This doesn't seem to prevent any significant amount of toil, since it can be pretty easily unrolled into existing JS syntax.