interop with new pattern matching proposal

[lin7sh]

The pattern matching proposal just made a huge progress. it's very useful and well designed on its own, but it would be great to works with tuple and record.

I haven't discovered any compatibility the following code should just work

match (tuple_or_record) {
  when (#["a", "b"]) { … } // tuple match
  when (#{a: 1, b: 2}) { … } // record match
  else { … }
}

please consider this integration and moving tuple and record proposal forward

[Jack-Works]

it brings an interesting problem. The record and tuple are designed to "transparent" to the user (which means they are both use normal x.prop to access property). Should this property also applies to the pattern matching? Which means:

match (#{a: 1}) {
    when ({a}) "matches!"
}

And what if the dev wants to match objects but not records, or wants to match records but not objects?

[ljharb]

Given that Records and Tuples are primitives, it would use === semantics if we made no changes to account for them.

Absolutely i think if the pattern is a record/Tuple, then it should only match on records and tuples. However, this seems to be asking about when the matchable is one, and the pattern is an object/array pattern.

Given that object and array destructuring will (presumably) work just fine with Records and Tuples, i think that there is simply no other option than making their patterns match against Records and Tuples. Thus, if you want to match records but not objects, you’d use a guard (which is a totally reasonable escape hatch for any comparison one wants).

Either way, whichever proposal advances second is the one that would have to account for this, so it seems like something that can be deferred until they’re both not at the same stage.

[tabatkins]

Given that Records and Tuples are primitives, it would use === semantics if we made no changes to account for them.

Not quite; we don't have a generic "any primitive" slot in the grammar. The "primitive matchers" are explicitly carved out as patterns (since, in particular, they're actually more than primitives, including some unary-operator expressions and well-known variable names). So the example in the OP would be a syntax error if we did nothing to accommodate it.

If they record/tuple was wrapped in ${}, like when (${#["a", "b"]}), then it would Just Work, using whatever equality semantics records/tuples used, because this extension point does have a generic "anything that doesn't have the Symbol.matcher method" clause that'll catch them.

I do agree that adding record/tuple patterns makes sense, and we should make sure that the second-mover proposal handles this.

[ljharb]

The spec for pattern matching is far from finalized; I suspect we would, actually, specify it using the same grammar productions that the language uses to parse primitives, with special cases for undefined and friends. Either way tho, it'd indeed be accommodated.

[rricard]

We expect pattern-matching to decide how they will handle Record & Tuple. Our champion group will be happy to review the interaction of pattern matching and Record & Tuple.

Since Record & Tuple already destrucuture like Objects & Arrays, we don't expect widely different behaviour here.