> There is no other programming language that has union types as powerful as TypeScript

Ada's record [0] type stands out. From what I can see, TS' unions are not nearly as powerful.

[0] https://en.m.wikibooks.org/wiki/Ada_Programming/Types/record

> There is no other programming language that has union types as powerful as TypeScript

I suggest looking into Idris and other languages with dependent types. Nothing against typescript, but it’s not even close.

Idris doesn't have anonymous sum types, nor does Coq or Lean. Which language were you thinking of?

Ceylon comes to mind; haven't googled others.

> There is no other programming language that has union types as powerful as TypeScript

How about Swift and OCaml? ReasonML comes to mind too. Haven't tried actively comparing any of them though.

OCaml/Reason have discriminated unions, which means that you have to explicitly specify which variant of the union you're using, such as

  type union = Bool of bool | Char of char | Nothing

  let (x, y, z) = (Nothing, Bool true, Char 'x')

Is this not what enums with associated values are?

Probably... but in any case TypeScript also supports naked (edit: I just made up the name) unions, where you don't need to declare them upfront, and where values of different types can be included directly. Such as:

  let a = random() ? 'a' : 1

TypeScript infers type

  string | number

This is still a discriminated union, only that the discriminator is provided by Javascript and is thus hidden: it's `typeof`.

Yeah, that's the runtime perspective... but for the type system, they're different... with the "naked" union being much harder (as they're non-algebraic - `a | b | b` always equals `a | b` and might even equal just `a` for some values of `a` and `b`)

No, this works on any overlapping types too - even unsound combinations such as `T | Array<T>`

Interesting! Thanks!

What features are you thinking of in those languages? I don't know Swift but I can't think of anything comparable in OCaml.

Sorry; I don't have much of an answer here.

I merely know from experience that they have a pretty good type system, but not much more. So I asked :-)

Answers have been enlightening

This doesn't need magic powers. All you have to do is treat literal values inside type descriptions differently.

Inside of type descriptions, literal values are always treated as literals. The problem only appears when you declare a variable _without_ an explicit type like `const foo = {k: 'x'}`, which the compiler then infers to be of type `foo: {k: string}` and not `foo: {k: 'x'}`.

Both of these are valid inferences, and it's impossible to know which one the user wants in the general case, which is why you have to explicitly say `const foo = {k: 'x' as const}`.

So the example of `false | 'x' | 'y' | undefined` turning into string is invalid?

I feel like I'm missing something.

here's a full example. If you do this:

    function test(p: {k: false | 'x' | 'y' | undefined}) {
        // do stuff
    }
    const p = {k: 'x'} // inferred type: {k: string}
    //...
    test(p); // type error : Type 'string' is not assignable to type 'false | "x" | "y" | undefined'
    

The problem is that the type of p.k is inferred to `string` not `x`. The compiler can't know this is fine because you could call `foo(p)` in between the declaration and the `test` call, that mutates p.k.

If you add `as const` or an explicit type to p it is fine.

(I think this is what the GGP was referring to)

Didn't realize "as const" worked; will have to try that next time.

Thanks!