Repository navigation
Design feedback from JSCIG #259
Description
Today I presented the current syntax and semantics to JSCIG and got the following feedback.
Still looks similar to switch
- The
defaultkeyword (but we cannot useelse) :as the separate token (looks likecase x:)- Current design has a strong visual hint (
:) that the RHS can be a statement but it actually cannot.
Should nest match shares the same cache?
const it = [0, 1, 2].values()
match (it) {
when ([a, b, c]): match (it) {
when ([a, b, c]): void 0 // can we reach here?
}
}@@matcher is a terrible name.
And even renaming it to something else is not solving the problem, because we cannot remove @@match and people will keep stuck on it.
How built-in @@matcher work exactally?
e.g. How Error@@matcher work?
Better try-catch?
try {}
catch when (pattern) {}
catch if (expr) {}
catch when (pattern) {}
catch {}
Activity
ljharb commentedon Jun 16, 2022
I agree on
default- I'd strongly prefer an alternative.I don't think
:matters because object literals already have that, as does TS types.:in the language (and in TS) is only followed by a statement with a label, but only an expression everywhere else, and since nobody uses labels, that seems like not something worth worrying about.ljharb commentedon Jun 16, 2022
As for "better try-catch", that's only something a followup proposal should do - see #239, #144, #18, #14.
ljharb commentedon Jun 16, 2022
Error[Symbol.matcher]would check for the presence of the [[ErrorData]] internal slot, I assume.tabatkins commentedon Jun 16, 2022
I continue to not have strong opinions on the
defaultname, but we already decided againstelsedue to it visually chaining with a precedingif()matcher. There's not a lot else we can do besidesdefaultif we don't have an official nil-matcher. (That is, I think we could removedefaultifwhen(_)was an auto-match that didn't generate a binding.)And yeah,
:doesn't suggest a statement anywhere besidesswitch; it carries an expression everywhere else in the language.(In general, tho, I don't have a problem with us slightly overlapping with
switchsyntactically, even if we have differences like this. It's fine, this is a fullswitchreplacement, it's something to learn once and never worry about again.)Yes, whatever the theoretically equivalent of
Error.isErrorwould do, which is gonna be some variety of brand check. The subclasses would brand-check for their specific subclass, etc.And yeah, I feel strongly that integrating pattern-matching with try/catch is something that would be good to do, but in a follow-up; it's not part of the core syntax and it's got enough complexity that it would drag the main proposal.
tabatkins commentedon Jun 16, 2022
Strongly inclined to say no. Using
itfor anything else in the RHS will show it already advanced an appropriate amount; it seems like it would be really confusing if using it in a match construct seemed to "rewind" it. Fragile, too, since you can do stuff likeit.next() && match(it) {...}in the RHS.noppa commentedon Jun 16, 2022
Has this been explored with matchers that would not be valid bindings anyway? E.g.
when(else)ljharb commentedon Jul 8, 2022
We should discuss further, but I think this doesn't need to block stage 2.
fuchsia commentedon Oct 22, 2022
Another choice of color for the bikeshed:
How about
doinstead of:And*has plenty of precedent as a wildcard. So it becomes:If do-expressions ever arrive, then you can incorporate them.
That avoids setting up semantics for blocks that ends up being different to those used in do-expressions. Hive off the arguments to that proposal.
ljharb commentedon Oct 22, 2022
This proposal will not advance past do expressions; it depends on them.
Jack-Works commentedon Sep 4, 2023
close for now because we're redesign things