It's a neat trick and I've used similar patterns in some of our projects, but in the end it doesn't buy you much over a `switch (x.kind) { ... }`. (Except your matcher can be used as a proper expression which is nice obviously)

But you don't have proper pattern nesting, fall-through semantics and it's not clear (to me yet) how to extend to matching on multiple values. Try implementing an equality function on a sum-type using pattern matching.

Having actual proper pattern matching added to TS would be such a great addition. Especially with full support of the control flow analysis.

This might be our best hope right now: https://github.com/tc39/proposal-pattern-matching

I see a lot of people asking for this in TS, but i'd much rather it be in plain JS and let TS add anything on top of it that is needed.

Pattern matching would work SO WELL in javascript, especially considering how frequently switch is currently poorly used as a replacement in things like Redux.

Yeah, but there's no way that can be the final syntax, because it's absolutely horrible (TS could always have a Rust/C# 8 one on top though).

I think the code is way too verbose. One supposed advantage of FP languages is that they are more concise. If I have to build a ton of boilerplate I might just as well go to some OOP pattern with interfaces and so on.

Remember that the point of the article is not what language does it best, but rather how to use typescript to add patterns from other languages.

True. I just think it's a mistake to force a pattern into a language that doesn't support it well. In the end you get sort of pattern matching but you have also to write a lot of code.

i did an article about quite a similar solution approach some time ago: https://pattern-matching-with-typescript.alabor.me/

having real pattern matching built in to TS would be awesome. nice write up though!

This article is totally on the same wavelength. I might have to link it as further reading on the subject. Any objections?

sure! go ahead. thanks :-)

Since typescript is compiled anyway it feels somewhat silly not to have the compiler do this work. I wonder how hard it would be to make the desugaring extensible, maybe with a rewrite engine like what Hermit does in haskell.

I'm disappointed in TypeScript not having pattern matching, multiple classes inheritance, and operator overloading (a MUST for game development)

I understand the sentiment, but really you should be disappointed in the ECMA standard, typescript only implements stage 3 and hire.

Don't think the "never" default arm is necessary. If the return type is set and you miss a case TS should complain.

You could use a typescript decorator to make it less verbose to setup I suppose. I would rather have a more native approach.