-
Notifications
You must be signed in to change notification settings - Fork 89
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
Shorter switch statements #169
Comments
Specifically, what does this issue ask of the proposal? The proposal's syntax already covers your example.
(This also shows that What does your example say about fall-through semantics? Consider that the proposal's syntax using a guard allows for fall-through using
It's hard to imagine not having to do this sort of thing in the guard, since we need a way to distinguish between referring to an already bound variable versus attempting to bind a variable. The proposal's syntax makes it clear that the attempt to bind happens in the pattern match and the reference to bound variables happens in the guard. |
@dustbort I guess @ANF-Studios suggested reusing |
Yes, kind of like switch expressions except they don't (necessarily) return a value, they are normal switch statements, but similar to it. |
Hey @ANF-Studios sounds like you're suggesting reusing the Some of those reasons being (non exhaustive)
Here are some other links (also non exhaustive)
While there is a lot of excitement about pattern matching in JS & sounds like you share some of that enthusiasm, I'm not sure pursuing using a |
The proposal has been updated in #174; the readme hopefully makes it clear why we won't be proposing any changes to |
I understand why the decision went against re-using the switch keyword and I don't have the intention to change that. But some of the points don't actually address the proposal that @ANF-Studios made.
C# got pattern matching pretty recently. They decided to re-use the switch keyword for expressions and changed the syntax for that: var result = someValue switch {
//...
} instead of the classical
The C# team partly did it that way because inventing a new keyword may break existing code and requires special handling for backwards compatibility. For example, when the This may also be relevant for a
The parser has to explicitly handle the edge case that there is a function called "match" as well as some look-aheads / speculative parsing respectively. Depending on the size of the argument of match, this might be a bit of work.
So I'd argue that inventing a new keyword is more complex than re-using an existing one, since keywords cannot be used as function names etc. The DX benefits must outweigh the complexity. |
That they’re separate constructs, grammar-wise, doesn’t mean they’re separate in the minds of users, especially when googling for help and documentation. The way the parser handles that case is with a “no LineTerminator here” (NLT) prohibition, which only causes a problem for those who want to write a match construct with allman style braces. However, that style is hardly ever used in js, and breaks with |
ASI has been responsible for some bad DX in the past. When designing a new feature, it would be beneficial not to make that feature prone to that again and hurt DX. Just using an existing keyword would make things easier and I think that this is what was proposed by ANF-Studios. It doesn't even have to be |
The approach I'm describing avoids ASI, which is the whole reason the restriction is needed in the first place. Additionally, the committee has explicitly decide that ASI hazards will never obstruct advancement of a feature - you should be using semicolons, not relying on ASI.
The choices are thus "a new keyword, using NLT" or "no pattern matching in the language, ever". I prefer the former. |
Switch statements are really cool, but it'd be nice if they could be shorter for one-line-code-actions.
Say we have a switch statement:
And for one line actions per case, this just gets overwhelming. I suggest that short switch statements get added.
An equivalent of that code above should look like this, shortened:
We can go one step further and inherit this from C#:
What this'll do is return bar (a variable declared somewhere) in a switch, as in.. a value depending upon the value of bar.
That'd make the code look a lot cleaner.
The text was updated successfully, but these errors were encountered: