Proposal-pattern-matching: Template Literal patterns with interpolations: ¯\_(ツ)_/¯

Created on 18 Jun 2021  Â·  5Comments  Â·  Source: tc39/proposal-pattern-matching

What happens if we do:

const b = 'B';
const c = 'C';
match ('a BCD XYZ') {
  when (`a ${b} ${c}`) { … }
}

What are b and c here? Would they refer to the string identifiers declared above, or would they be irrefutable matches and bind b to 'BCD' and c to 'XYZ', or what?

Options seem to be:

  1. decide that inside a template literal pattern's interpolation curlies, everything is always in "expression mode"
  2. come up with matching semantics as described above
  3. ban template literals with interpolations (but allow ones without)
  4. ban all template literals
champion group discussion design idea question

Most helpful comment

They absolutely shouldn't be matchers; that would be extraordinarily weird and add a ton of complexity for no good reason.

I'd find it acceptable to say that template literals aren't a literal pattern and can only be used in the pin operator (where their execution and visible bindings is well-defined) as well, but if we can get away with avoiding that and just allowing them as patterns (where the ${} bits see the same bindings they would as if they were in a pin - aka the outer match() context + the root matchable if it's bound in the head) I'd prefer to do so.

Another thing to consider is how template tags should work - are they allowed or not?

Those are just function calls, and definitely should be allowed only in the pin operator.

All 5 comments

This is really interesting. At first glance, I would expect interpolations to behave the same way as they would in a template literal _outside_ a match construct: in other words, option 1. Does that approach create problems I'm not seeing?

For point 2, whatever matching semantics we come up with would just be a weaker form of regular expressions, and I don't know if there's any good way to come up with good matching semantics.

For example, how would you match the string xxxxxxxx with x${a}x${b}x?

I would rather developers just have to learn how regular expressions work alone, and not have to additionally learn pattern-matching with template literals.


Another thing to consider is how template tags should work - are they allowed or not?

They absolutely shouldn't be matchers; that would be extraordinarily weird and add a ton of complexity for no good reason.

I'd find it acceptable to say that template literals aren't a literal pattern and can only be used in the pin operator (where their execution and visible bindings is well-defined) as well, but if we can get away with avoiding that and just allowing them as patterns (where the ${} bits see the same bindings they would as if they were in a pin - aka the outer match() context + the root matchable if it's bound in the head) I'd prefer to do so.

Another thing to consider is how template tags should work - are they allowed or not?

Those are just function calls, and definitely should be allowed only in the pin operator.

I mainly wanted to enumerate all the options first :-)

I suspect that the only viable choices are indeed 1 or 4, and yes, tagged literals can only be used in an expression context.

I guess if you were crazy enough to try option 2, you could aim to mirror the semantics of TypeScript's type-level template string inference... 😅

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Haroenv picture Haroenv  Â·  6Comments

caub picture caub  Â·  8Comments

JLHwung picture JLHwung  Â·  3Comments

arcanis picture arcanis  Â·  6Comments

JLHwung picture JLHwung  Â·  6Comments