-
Notifications
You must be signed in to change notification settings - Fork 89
Why not more connection to destructuring? #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I guess there is more connection than I thought on first glance. The comments
make it clearer. I still was pretty confused by the special-casing for other patterns, so I think adding some explanation of how matching cannot be completely done via destructuring because you want to match values that are not objects or arrays would be helpful. That was where I got confused at first; I was under a vague impression that pattern matching just kind of automatically fell out of destructuring, so seeing all the other stuff for literals and identifiers was confusing. That confusion might be unique to me though. Feel free to close if you think it's clear enough as-is. |
I should add more about this topic. Essentially if you limit the patterns to just the array and object patterns you have what you'd expect. This proposal takes a few further steps because they're very very useful for pattern matching in practice. |
Pattern matching with destructuring is invaluable when you have it everywhere, especially in function calls. In JS syntax it would be something like
I guess this is what people would love to have, but, I guess, is impossible to properly implement in JS |
When people theorized about pattern matching syntax in the past, it was always very related to destructuring, using the same syntax in most cases. I can appreciate there are probably reasons to depart, but I think it'd be useful to have a section explaining the connection, or lack thereof.
The text was updated successfully, but these errors were encountered: