The TS code indeed looks cool. This is an area we're looking at.
One point, though: we try to be very careful to not regress performance or developer iteration time (e.g., type checking time) when we introduce new language features. E.g., structural typing can be more expensive in general to type check since we need to recurse.
Have you considered not going full-on structural-typing but still providing some sort of union? In fact, you could go for one with even stronger guarantees, like the sum types in Rust or F#. (with Rust going as far as to call them enums too)
I'll admit I have the faintest notion on what causes that kind of complexity on a compiler, so my suggestion might be an even worse idea.
> Have you considered not going full-on structural-typing but still providing some sort of union?
I work on Dart. The terminology gets really confusing here. "Discriminated unions" and "union types" are two quite different things, though they get a little blurry in TS.
The short answer is, yes, we're investigating pattern matching with exhaustiveness checking and making the language more graceful at expressing algebraic datatype-style code. The last half of that sentence sounds weasely because any object-oriented language can (except for exhaustiveness checking) model an algebraic datatype using subtyping. The parent comment using an abstract base class is how you do it.
So there isn't anything really fundamental that Dart can't express already. It's mostly a question of giving users syntactic sugar to make code in that style look more terse and familiar. I personally really like pattern matching and ADTs and I also particularly like multi-paradigm languages, so this is a subject close to my heart.
The language team has been pretty busy with null safety, but now that that's out the door (woo!), we can start working on the next batch of features, which with luck includes pattern matching. Here's an in-progress proposal:
No time frame, sorry. We generally don't make promises about future dates because schedules tend to be flexible and picking dates just sets people up for disappointment.
The TS code indeed looks cool. This is an area we're looking at.
One point, though: we try to be very careful to not regress performance or developer iteration time (e.g., type checking time) when we introduce new language features. E.g., structural typing can be more expensive in general to type check since we need to recurse.