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.

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.

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!

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)

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.