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:
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... 😅
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 outermatch()context + the root matchable if it's bound in the head) I'd prefer to do so.Those are just function calls, and definitely should be allowed only in the pin operator.