Proposal-pattern-matching: Ability to no-bind multiple slots

[tabatkins]

Haskell blesses the _ identifier in match expressions to match anything but bind nothing; as a result, you can use it in multiple places in the match expression to indicate multiple holes you don't care about.

It's not clear from the README whether binding the same name multiple times would be an error or not, but if it is, this would conflict with this useful Haskell ability.

[bterlson]

This is a good point - if we aligned with destructuring declaration semantics (which seems best, generally) then this would be an error. I would not be opposed to bestowing Haskell powers on _ myself.

[itsMapleLeaf]

It's more idiomatic in JS to match for undefined and null, I think. The underscore is used as a valid identifier in lots of places. It'd be strange for it to suddenly mean "nothing" in one place specifically.

[dmitriid]

Add a "meta" property to Symbol? Something like Symbol[@none]?

[bterlson]

underscore is used in a lot of places, but I think many of those places are already "I'm ignoring this parameter". It seems like underscore would very likely be a bad name for any field pulled out of a pattern, but I could be wrong.

[ljharb]

I think selecting any single symbol like _ will be confusing and hard to read. In Scala, for example, it's got so many meanings that to understand what it means in a specific context, you have to either memorize or have a magic non-universal "intuition" about it.

Having a placeholder token seems very useful! I just hope if we add it, it ends up being something unambiguous.

[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).

As my response to this specific issue, though: I think we should do whatever function(){} here does, because that's what JS devs will be used to as far as sequentially binding names. That means that you should use different identifiers, and use your own practices to mark certain parameters as ignored (I personally prefix unused params with _, so function (_foo, _bar, gimmethis) { ... }). This spec issue might be a bit less relevant now that identifiers are irrefutable binding patterns now, rather than potentially matching values in the surrounding scope.