Proposal-pattern-matching: Alternative - allow specifying comparison expression in `switch`

[PaulKiddle]

Pardon me if this has been suggested before - it strikes me that this proposal could be made more broadly useful by allowing developers to specify the comparison used by switch.

Assuming we want to check an object for the presence of a particular key, we could then have syntax like this:

const subject = { error: new Error('Something went wrong') };

switch(case in subject) {
    case 'children': return <Component>{subject.children}</Component>;
    case 'error': return <Error message={subject.error} />;
}

Here the case keyword in the switch statement is a kind of pseudo variable, and its presence indicates we're providing a comparison expression.

(NB: for a more complex nested shape we might need to introduce some way of representing object shape as a value, and some way of comparing it)

This could then be used in many other patterns, like error checking:

switch(error instanceof case) {
    case TypeError: return "It's a type error";
    case CustomError: return "It's a custom error";
}

Or routing:

switch(url.match(case)) {
    case /^\/photos\/[0-9]+/: return "See a specific photo";
    case /^\//: return "Get the home page";
}

I've added a repo with a more detailed overview: https://github.com/PaulKiddle/switch-comparison-expression-proposal

[PaulKiddle]

Quick update - I've read some of the other issues and I know @ljharb has said he doesn't like the idea of making this proposal too similar to switch, but I think splitting the proposal into "pattern matching operator" and "multiple test case switcher" would deliver the aims of the proposal while introducing two independent language features with much broader usage potential.

If others think that's the case I'd be happy to follow this switch idea up as a separate proposal, allowing this proposal to focus on how to implement a pattern matching operator without needing to worry about switching on multiple return values.

[ljharb]

@PaulKiddle i'd be strongly opposed to any proposal that makes switch better; i think it's a terrible tool that needs outright replacement, and that it'd be actively harmful to the ecosystem to make it _more_ tempting to use than it already is.

[dustbort]

A key of the proposal is to have a pattern matching _expression_, as opposed to a _statement_ (i.e., switch). Things are moving in the functional direction, which points to _expression_.

[nicoburns]

@dustbort It seems to me that there is no reason why a pattern matching expression couldn't use the switch keyword. It could be distinguished from a normal switch statement by the absence of the case keyword. This would give all the advantages of this proposal, with the added benefit of not having to introduce a new top-level keyword.

[ljharb]

@nicoburns it will not use the switch keyword, partially because that would be confusing to google and see examples describing the old switch and the new one, and partially because i want no association to the switch statement.

[PaulKiddle]

There are plenty of things across programming languages that are hard to google for various reasons, I don't think that's a very compelling reason to discount something. The introduction of for(x of y) in Javascript would be a similar case.

In terms of the problems with switch, this could be an opportunity to fix them. A switch(expression) statement could require a break or return for each case statement, or create a new block scope for each case. Whether or not that would be too confusing for users used to regular switch would need discussing, but it definitely has benefits.

[ljharb]

This proposal will provide a replacement for switch, whether in statement or expression position. As such, it can’t have any overlap with switch.

[hax]

I understand why Jordan don't like reusing switch, but I feel C#/Java already choose that way and seems ok. So maybe we don't need to give a conclusion too early. It's more like a bikeshed issue.

[ljharb]

I can assure you that nothing will ever advance if it overlaps with switch.

[treybrisbane]

@ljharb Is it worth just creating a pinned issue called "Why this proposal _won't_ be reusing switch"? 😅

[ljharb]

@treybrisbane the entire repo will be overhauled in the medium future, and that will be apparent from the readme.

[PaulKiddle]

tbh I think the name is a red-herring here, the main idea I wanted to get across is this:

This proposal introduces two new things:

• a construct for branching code in a more generic way than just checking cases for equality with a subject (essentially what I was describing in my issue)
• an expression for testing an object against an object-pattern

While both of these work nicely together for specific use cases, they are also both useful individually (and if available individually would be applicable to more use cases).

As it stands, the second part (object pattern matching expression) introduces a lot more new and complex syntax and therefore potential for bike-shedding and other things that are going to drag out the approval process - and hence the approval of the first statement.

Conversely, if I'm wrong and the code branching construct turns out to take longer to approve, that is going to unnecessarily delay approval of the object matching expression.

Either way, I think it makes sense to split this into two separate proposals.

[ljharb]

The proposal will be introducing many more new things than that; please be patient for the update after we present to TC39 this week.

We won't be proposing any improvements to switch.

[ljharb]

The proposal has been updated in #174. The readme should hopefully make the above clear.

Please file a new issue if, taking into account the updated proposal, you still have concerns.