At this point TS is trying to keep runtime syntax in line with TC-39 (the language committee in charge of JS) proposals that reach Stage 3 (and thus likely to reach Stage 4 and general acceptance/use in the browser).

There is currently a Stage 1 proposal for a pattern matching syntax presented to TC-39. If it reaches Stage 3 then it is presumed likely Typescript will implement it.

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

Not any time soon AFAIK. TS aims to be syntactically identical (minus the type system obviously) to JS, so no new constructs.

It’s not clear it’d be worthwhile, anyway - TS doesn’t support algebraic data types directly, which is the big use-case for pattern matching; and the type system is smart enough, with some careful massaging, to do exhaustiveness-checking when using ifs or switches and the standard pattern for simulating them.

I don't think that's possible since types are not present at the runtime. They are just stripped away during compilation

It would still be possible as long as all the necessary information is available at compile time.

Dispatch during pattern matching happens at runtime, which requires some means of discriminating the matched values with run-time information. Typescript doesn't provide any more runtime type information than Javascript does, and so it can't see the difference between "Object" and "Object" unless the object has fields that allow it to, such as the class constructor or programmer-specified values. I don't think that the compiler adding additional information to discriminate types other than what JS already provides fits with the design goals of Typescript being a language that only adds static typing.

I hope so. As a Rust fan I was glad I learned TS for the situations I do more web-focused work. The union types are usually good enough as enum replacement, but good pattern matching would be yet another improvement.