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
Alternative - allow specifying comparison expression in switch
#168
Comments
Quick update - I've read some of the other issues and I know @ljharb has said he doesn't like the idea of making this proposal too similar to switch, but I think splitting the proposal into "pattern matching operator" and "multiple test case switcher" would deliver the aims of the proposal while introducing two independent language features with much broader usage potential. If others think that's the case I'd be happy to follow this |
@PaulKiddle i'd be strongly opposed to any proposal that makes |
A key of the proposal is to have a pattern matching expression, as opposed to a statement (i.e., |
@dustbort It seems to me that there is no reason why a pattern matching expression couldn't use the |
@nicoburns it will not use the switch keyword, partially because that would be confusing to google and see examples describing the old switch and the new one, and partially because i want no association to the switch statement. |
There are plenty of things across programming languages that are hard to google for various reasons, I don't think that's a very compelling reason to discount something. The introduction of In terms of the problems with |
This proposal will provide a replacement for switch, whether in statement or expression position. As such, it can’t have any overlap with switch. |
I understand why Jordan don't like reusing |
I can assure you that nothing will ever advance if it overlaps with switch. |
@ljharb Is it worth just creating a pinned issue called "Why this proposal won't be reusing |
@treybrisbane the entire repo will be overhauled in the medium future, and that will be apparent from the readme. |
tbh I think the name is a red-herring here, the main idea I wanted to get across is this: This proposal introduces two new things:
While both of these work nicely together for specific use cases, they are also both useful individually (and if available individually would be applicable to more use cases). As it stands, the second part (object pattern matching expression) introduces a lot more new and complex syntax and therefore potential for bike-shedding and other things that are going to drag out the approval process - and hence the approval of the first statement. Conversely, if I'm wrong and the code branching construct turns out to take longer to approve, that is going to unnecessarily delay approval of the object matching expression. Either way, I think it makes sense to split this into two separate proposals. |
The proposal will be introducing many more new things than that; please be patient for the update after we present to TC39 this week. We won't be proposing any improvements to |
The proposal has been updated in #174. The readme should hopefully make the above clear. Please file a new issue if, taking into account the updated proposal, you still have concerns. |
Pardon me if this has been suggested before - it strikes me that this proposal could be made more broadly useful by allowing developers to specify the comparison used by
switch
.Assuming we want to check an object for the presence of a particular key, we could then have syntax like this:
Here the
case
keyword in the switch statement is a kind of pseudo variable, and its presence indicates we're providing a comparison expression.(NB: for a more complex nested shape we might need to introduce some way of representing object shape as a value, and some way of comparing it)
This could then be used in many other patterns, like error checking:
Or routing:
I've added a repo with a more detailed overview: https://github.com/PaulKiddle/switch-comparison-expression-proposal
The text was updated successfully, but these errors were encountered: