Proposal-pattern-matching: How to match multiple patterns (empty legs, &&, ||)

[domenic]

Implicit fall-through is bad in switch because you have to manually insert a terminator, so in cases where you have an interesting body, you still fall through if you forget the terminator.

However, in this proposal, there's an obvious automatic terminator: the end of the expression or block.

So I think there's room for implicit fall-through, in the case that something is not terminated. Which is only when there is no body. Consider:

const result = match(node.type) {
  "tag":
  "script":
  "style":
    createElement(node);
  "root":
    createDocument(node);
  "text":
  "comment":
  "cdata":
    createText(node);
};

Forcing me to add continue;s here seems pointless. It's much more likely that I meant for there to be a fall-through, than that I just forgot to write a body for tag/script/text/comment.

[bterlson]

Interesting, good point! Will consider this.

[bterlson]

Also worth noting that the optional extension "multiple patterns" would allow something like:

const result = match(node.type) {
  "tag" || "script" || "style": createElement(node),
  "root": createDocument(node),
  "text" || "comment" || "cdata": createText(node)
};

[itsMapleLeaf]

I think commas instead of || would read a lot better there. It fixes the need for a multi-value fall-through (which aren't that common to begin with) and happens to be the approach taken by other languages adopting the syntax.

[nafg]

Scala uses |

[dmitriid]

IMO comma becomes a bit unreadable when you introduce objects into the mix:

const result = match(node.type) {
  {x, y}, {x, y, null}, {x, ...y}:
     something
};

which can somewhat be improved by formatting it:

const result = match(node.type) {
  {x, y},
  {x, y, null},
  {x, ...y}:
     something
};

|| (quite easily discernible as or), may be better for such cases

[domenic]

I still think : is better than || or ,

[ljharb]

I would prefer to avoid implicit fallthrough precisely because it's implicit - it seems like explicit "multiple patterns" might obviate any benefit from fallthrough.

[domenic]

Well, my argument is that it's not implicit, really. You explicitly chose to not have a body.

That's unlike the switch case, where you forgot to add break;.

[ljharb]

I agree that only allowing fallthrough when there's no body avoids much of the switch hazard.

In that case tho, it sounds like what you want is a way to have multiple matching patterns - is there a use case where "any reasonable form of multiple patterns" wouldn't cover it?

[domenic]

As far as I can tell they're equivalent. : just avoids introducing new syntax.

[bterlson]

The benefit of the new syntax is that you can use && and || as opposed to the empty-leg form which only allows the || equivalent.

If we want to allow && and || patterns (or allow for their future inclusion) I would prefer to make empty legs an error for now. If we don't want to go that route, empty legs for explicit fall-through seems clearly better.

[rntz]

Colons ("empty legs") don't nest. || and && do; for example, {x: Number || Array}. I think that's a strong reason to prefer || (or something that acts the same; I'm voicing support for disjunction and conjunction patterns, not for a particular choice of operator syntax).

[dmitriid]

Conjunction/disjunction is actually future-proof. Imagine JS adding function (and other) guards or similar. See Erlang for example: https://en.wikibooks.org/wiki/Erlang_Programming/guards

[rattrayalex]

Some kind of support for this seems vital.

I personally find || most alluring, but it comes with the expectation that && will work as well. This can get confusing, since developers might expect && to essentially "leave the pattern context", allowing things like { x: 0, y: 0 } && allowOriginPoint – which wouldn't do what you might think. && also doesn't really make sense in a pattern context – do you want something to match an object and an array? The only time it'd be particularly useful would be predicates (a topic for another thread).

If || is used without allowing &&, some amount of "user research" should probably be conducted to ensure it won't be too confusing/surprising - and the error messages should be nice.

[borela]

Implicit fall-through is bad in switch because you have to manually insert a terminator

No, the terminator is a really great visual cue to know where it ends.

IMO the pattern matching should work like a switch because it does a similar job and people who are starting to learn JS, will assume it behaves in a similar way.

[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 categorizes alternatives like this as "future work" because it's a fairly big feature onto itself and potentially involves a _lot_ of bikeshedding in order to support. There's a pretty big section about it in the "Beyond This Spec" section, though, so I'd love it if this was done once this proposal is a bit further down the line. I don't think it's worth holding up the proposal for, and I don't think this is an essential feature in order to land match. There's already matching engines that get away with not having compound matchers and are still plenty useful for real applications.