Proposal-pattern-matching: Binding an outer form

[tabatkins]

In Haskell's matching syntax, it's possible to specify a nested form, but also bind the outer object to a variable name. A pattern that splits a list into a head/tail might be (x:xs), binding the head to x and the tail to xs, while one that also binds the entire list might be s@(x:xs), binding the list to s.

(This is a more general requirement for destructuring; it just also applies here.)

[tabatkins]

It looks like we can rely on the outside binding of the matched expression to take care of an outermost binding, but you still can't get interior ones in all cases - [x, [...]] won't let you bind the second element of the array. This also does mean you can't easily get the value of an expression being matched; you have to bind the expression's value first, then match it, which is annoying.

I think this is, in general, just a problem with the array form? Object notation appears to work fine - I think {x, y: {z}} will bind y to the value of the y property?

[tabatkins]

Note that https://github.com/tc39/proposal-pattern-matching#else-leg-syntax invokes this concern - it proposes a special identifier that matches anything and binds it to the special name, precisely so you can get access to the result of the expression being matched without having to bind it to a name outside the match expression. There's no reason to limit this concern just to "else" blocks - if you need to solve it in one place, you'll need to solve it in others.

(With the "matches anything" special built-in you talk about in #6, you could get the desired else semantics with a foo@anyvalue: ... pattern.)

[rntz]

The proposal mentions possibly allowing pattern conjunction - requiring a value match multiple patterns. Then, if #11 gets solved and there's some way to write a pattern that always binds the name x, you can accomplish this via &&: s@(x:xs) becomes s && (x:xs). This is how Racket's match handles this problem, for example.

[zkat]

Hey y'all! #65 has gotten merged, and a lot of issues have become irrelevant or significantly changed in context. Because of the magnitude of changes and subtle differences in things that seem similar, we've decided to just nuke all existing issues so we can start fresh. Thank you so much for the contributions and discussions and feel free to create new issues if something seems to still be relevant, and link to the original, related issue so we can have a paper trail (but have the benefit of that clean slate anyway).

The new proposal mentions this particular feature, though, and the conclusion is that it's best left to future spec work. While I think this is super handy and fairly important (and widespread among pattern matching/destructuring engines), I think it's a potentially big bikeshed and I think we're -much- better off having the work focus around improving the current destructuring syntax, and match will reap the benefits of that directly.