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.
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.
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.
