relationship with pattern-matching proposal

[Jack-Works]

https://github.com/tc39/proposal-pattern-matching

[ljharb]

I'd personally block any attempt to improve or alter switch in any way - switch statements are an abomination and should not be made easier to use - they should instead be replaced wholesale with something better (like pattern matching).

[SebastianSimon]

@ljharb
I fully agree. I see no benefit in this proposal, because, for the provided example, a pattern like this can be used instead:

const color = (type) => ({
    apple: "red",
    banana: "yellow"
  }[type] ?? "invisible");

Much more compact, much more maintainable. If the underlying mapping object (or a proper Map) is stored elsewhere, it can even be dynamically extended, manipulated, and even serialized.

If this switch–return syntax is used for side-effects, this definitely feels like an anti-pattern.

[hax]

Note Java/C# all improve and provide a better switch.

[ljharb]

I think JavaScript can aim much higher than matching Java or C#.

[Jack-Works]

Note Java/C# all improve and provide a better switch.

Pattern matching is the better version of switch

[hax]

In C#, better switch is just one of pattern match feature: https://docs.microsoft.com/en-us/dotnet/csharp/pattern-matching#using-pattern-matching-switch-statements

[hax]

I think JavaScript can aim much higher than matching Java or C#.

I am confused why we should always put JS to the position opposed to other successful mainstream languages like C#/Java. Of course, we do not need to copy feature just for make JS look like Java/C#, but we also does not need to always refuse adopt a similar design in order to make JS look different from Java/C#. Especially switch in Java/C# had faced a very similar issues with switch in JS.

If it is not a careful examination of the pros and cons of various solutions, but a priori assertion that a certain design must be rejected, in my opinion it's an irresponsible arrogance.

[gmarcos87]

I didn't make this proposal trying to compare JS with other languages, I feel good with JS and I think it is one of the languages that gives the best user experience.

The origin of this was that I spent almost a year working with Kotlin, until I finally went back to JS (where I feel much more comfortable). In this return I realized that I missed some things from Kotlin that I found intuitive and compatible with the JS mindset but that we didn't have. Among them a way to return values from the Switch, or even from a try/catch.

I base this on the feeling that it is something to be expected (the return), that it would have an instant adoption and without generating confusion about its use. It simply makes it easier to read the code and to understand the origin of the value assigned to a variable.

I think async/await went that way and had very good repercussions.

[ljharb]

@hax you're exactly right that they’re not opposed, and that we should always consider what other languages have done - but that doesn’t mean “matching another language” should be a justification for anything in and of itself.

@gmarcos87 my opinion is that it’s impossible to use any form of switch and not have confusion about its use. I consider that well irrevocably poisoned.

[IgorKhomenko]

It seems it can be well achieved via pattern matching

const color = match(type) {
  when ("apple"): "red"
  when ("banana"): "yellow"
  default: "invisible"
}

So probably pattern matching is a way to go since it's more powerfull in all the aspects