Proposal-pattern-matching: why do-expression instead of function body?

[Haroenv]

using the semantics of do-expressions means that pattern matching can only be finalised when do-expressions are also finalised, unless there's no chance in the final semantics changing on do-expressions.

has there been an option where the rhs behaves more as an arrow function body?

Is this considered potentially an issue for the champions, or irrelevant since they would both land at the same time?

[ljharb]

Function bodies have return values, may bind super and arguments, and cant return from the match-enclosing function (or break/continue out of a match-enclosing loop); you’d also be unable to await when the match construct is inside an async function nor yield when it is inside a generator. do expressions allow any statement (that has a sensible completion value; see #173). Additionally, it might be confusing to have function body semantics without actual function syntax.

That said, we’re still in stage 1, so there’s definitely plenty of time to consider alternatives like this one!

[Jack-Works]

do expression is much more simpler than the pattern matching so I think it's safe to use its semantics

[ljharb]

As for proposal timing, I’d put money on do expressions advancing before pattern matching, both due to relative complexity, as @Jack-Works indicates, and due to how close do expressions are to being eligible for advancement.

[Haroenv]

Makes sense, thanks for responding! I think this makes sense. Personally I feel like this might make the adoption a little more work, since you need to understand the do-expressions too, but if the order they land is do-expressions first, that feels fine to me

[ljharb]

I agree!

Given that, I'll close this, but I'm happy to reopen it if there's a need.

[mpcsh]

since you need to understand the do-expressions too

Just to address this: the reason that I advocated for using do-expressions in the champions' group discussions was that it's the closest thing we can get in JS to "just a block". I hope that folks will be able to use the construct we come up with without needing to fully understand how the RHS is implemented.