Repository navigation
Statement version of match expression #294
Description
The plan we already have is to wait for https://github.com/tc39/proposal-do-expressions advance.
I've heard that the author has lost interest on that proposal, maybe we should consider what if we will never have do expression.
A possible solution is to have MatchExpression and MatchStatement, where MatchStatement can contain other statements.
for (const expr of exprs)
match (expr) {
default: { continue };
// ~~~~~~~~~~~~ block in statement position
}
for (const expr of exprs)
x = match (expr) {
default: { continue };
// ~~~~~~~~~~~~ object literal in expression position
}
Activity
ljharb commentedon Sep 4, 2023
I'm still interested in seeing do expressions advance, and I think we could do a follow-on match statement proposal later if it's indeed deemed to be something that will never happen.
hax commentedon Sep 8, 2023
It's really bad that
default: { value }would change semantic if people add/removex =beforematch.Personally I think the thing after
default:should always a statement, to be consistent withdefault:inswitchorlabel:syntax. (Actuallycase X:anddefault:are just special label as the original source of the syntax from C). This might one of the small reason why Java choose addingcase X -> expressionsyntax.ljharb commentedon Sep 8, 2023
I agree that would be bad; that’s not what I’d expect we’d do.
This proposal is explicitly not trying to follow the many broken choices of switch (and if consistency with “label” occurs to someone, that’s a strong argument to not use the colon at all).
tabatkins commentedon Sep 8, 2023
Right, the current plan is that the match expression continues with its current semantics and requirement that the match arms are expressions. If do-exprs never advance, we'll add something to match expression to allow statements in there.
Oh gosh absolutely not, the
defaultbranch shouldn't use a different parsing context to every other branch. "Consistent with switch" is not only an anti-goal here, it's not coherent anyway; switch hasdefault: <statements-here>because it also hascase foo: <statements here>. The consistent position for the match expression is to also have expressions in bothwhen foo: <expression>anddefault: <expression>.theScottyJam commentedon Sep 9, 2023
If do expressions to not advance and we were to add something to pattern matching so you could do statements in the RHS, would we also consider allowing some way for this "RHS block" to provide a completion value, the same way you can do with do expressions?
If so, we're basically replicating the functionality of do expressions with pattern matching, in fact, you could basically build-your-own clunky do expression with
return match (null) { when (null) { ...look at me, I'm basically a more-verbose do expression } }. And, I sort-of doubt that would fly if do-expressions don't achieve consensus (though, we'd have to see).If not, it's a bit of a shame - it basically encourages you to resort to IIFEs if you need your block to have a completion value, as the syntactic alternative pattern-matching provides wouldn't be powerful enough for these kinds of use cases.
ljharb commentedon Sep 9, 2023
Yes, that’s what I’d envision - a follow on to add do expressions only in the RHS of a when.
hax commentedon Sep 12, 2023
@tabatkins Yes you are inventing consistent "when:" and "default:" but it doesn't change the fact that "default:" in match is inconsistent to "default:" in switch, not only JS, but also all mainstream C family "default:".
hax commentedon Sep 12, 2023
Note, do expression (as current do expression draft) never solve
default:inconsistent issue, because do expression can't be put in the place of statement.default: do { ...always be parsed asdo whilenot do expression if keep consistency.