No and that’s one of biggest problems, pattern match is runtime decision not compile time one. It’s a shame because pattern matching with algebraic types is the full picture of the whole thing. Without it it’s just one-legged weirdo. It would be possible to emit runtime checks, similar to how tcomb+flow does it, but that’s not gonna happen anytime soon.

You can use switch statements for a pattern matching analogue. See the "Exhaustiveness Checking" heading at https://www.typescriptlang.org/docs/handbook/advanced-types.....

The goal of typescript is to provide static type analysis at compile time and mimic Ecmascript spec features. If Typescript starts bundling a runtime with it to do things completely unrelated to Javascript, then it's not just javascript with types anymore, it becomes its own language which defeats the entire purpose of Typescript.

This trade off is good because there is no runtime overhead, only desugaring. Typescript should never become ML or anything else that Javascript is not. If you want pattern matching in Typescript you need to convince the Ecma committee to put pattern matching into Javascript first.

Your comment seems like a non-sequitur. What does pattern matching have to do with runtimes?

Isn't one part of pattern matching to ask for a type and the other to ask which values the (instance?) of that type holds?

When a language has algebraic data types -- i.e., data types that have multiple, disjoint constructors -- pattern matching generally means determining which constructor was used to create the value being matched, and branching on that. I'm guessing this is the kind of pattern-match that TypeScript users would be eager to have.

What I don't see is how this requires the addition of a "runtime" on top of the JS model to make it work. I don't use TypeScript, and don't know how it implements its data types, so there may be something obvious here that I'm missing.

Pattern matching doesn't require any kind of runtime support, and can be implemented through desugaring.

How so?

Why would it need runtime support? It would just desugar into an if-else chain.

I believe there was/is a stage 0 proposal for pattern matching in ECMAScript

Stage 1 and yes, this one simply uses destructuring.

But it could use JavaScripts own types.

But it couldn't use TypeScripts types.