proposal-pattern-matching: Match expression should loosen the restrictions of the do expression if it's Completion Value is not used

Now the do expression semantics bans the following code:

const x = do {
    for (const y of z) y.work()
}

Since pattern matching is using semantics of do expression in the RHS, this restrictions also applies to the match expression.

// SyntaxError!
const x = match(z) {
    when([x, ...y]) {
        for (const q of y) q.work()
    }
}

But this restriction does not make sense if the match expression is used as an ExpressionStatement and its Completion Value is not collected by another MatchExpression or DoExpression.

// Also SyntaxError but doesn't make sense
function handle(z) {
    when([x, ...y]) {
        for (const q of y) q.work()
        // Also SyntaxError, but why?!
    }
}

We should make it valid.

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 1
Comments: 16 (14 by maintainers)

Most upvoted comments

Ehhhhhhhhhh. I think the argument from TCP gets much stronger if you’re actually using the do keyword, which this proposal seems not to be.

do expressions ban this specifically because we want to prevent someone from observing the completion value of a loop. But if the match is in statement position, you don’t observe that value. (That also applies to do in statement position, of course, but there is no reason to ever do that, so the restriction doesn’t arise in quite the same way.)

bakkot on Apr 21, 2021

That’s an opinion I’m coming around to, the more we all talk it out.

ljharb on Apr 22, 2021

That’s a strong argument for picking one of the options that uses do (or whatever keyword do expressions end up with) in #181, but remains an argument to close this issue, so we match do expression semantics (whatever they end up being). Thoughts?

ljharb on Apr 22, 2021

That’d certainly be a less complex way to specify it - but it seems like it’d still be incredibly confusing for users.

I can think of function and class declarations’ hoisting behavior (which only changes their availability, but not their semantics), and object literals vs blocks (which are a huge source of confusion). what other code has different semantics in expression vs statement position?

ljharb on Apr 22, 2021

I think it would be very confusing, and violate Tennant’s Correspondence Principle, if the location of the match expression altered its semantics.

It simply doesn’t make any sense to do that, because it is an expression, and it’s also a do expression, where that’s banned.

ljharb on Apr 21, 2021