Another very common case in TypeScript (and other languages) is union types. Other languages have constructs for checking the underlying type of a union type directly, but typescript is smart enough to figure it out based off of the properties of the constituent types and what you've checked so far in your code.

e.g.

    interface A { type: 'a' }
    interface B { type: 'b' }
    type C = A | B;

    const c: C = ...;
    if (c.type === 'a') { /* c is of type A here */ }

That's basically case 1, right? The compiler knows which type is being used at each call site, so it can generate a separate function for each type in the union and eliminate the type check/dead branches.

I guess the exception would be if you have a non-homogenous array that you try to map over. In that case there's probably no way around boxing the values.

For consts and function arguments yes, I think. But you could have some mutable variable or field whose value depends on runtime state. In that case, you could have an actual polymorphic type.

But the previous example isn't that case.

if (c.type === 'a') { /* c is of type A here */ }

This is dynamic typing, this code is checked at runtime, and it's leveraged statically.

Yes, that's correct. In the GP example, c was const, so the type can be determined at compile time.

I was writing TypeScript, where const just means the variable is not reassigned. For instance this is valid:

    const c: C = Math.random() < 0.5 ? { type: 'a' } : { type: 'b' }.

Ah, I'm sorry. You're right of course!

It actually happens all the time, which is why the suggestion is valid (namely that flow typing is useful). Flow typing is deeply related to union types, at least for expression-based languages.

Take rust. You have a function that on one path of a branch returns an int, in the other, a float. Rust says that's an error. I say your function returns a union type :)

And this is totally pervasive. A function which returns an int in an if branch (w/out an else) and elsewhere returns nothing actually returns an optional.

A variable which is assigned in one branch to a reference to an int (an l-value in languages that screwed this up, like rust; a ptr int in languages that, sensibly, use types to encode this property, like algol68) in one branch, and to an int value in the other, is technically a union type. If that union is added to a to a float - that shouldn't be an error! The int should be widened, the ref int should be dereferenced, then widened.

OTOH, if you try to assign an int to that union - now that is an error, because values can't be assigned to. You can only assign to types which represent a location in memory, like ref int, unlike int.

In the above discussion, the effect of control flow on the types is critical. Languages like rust ignore this, and to my mind, their ergonomics suffer considerably because of this. C++ side-steps this through statement based syntax, which makes variant types clunky.

Union types are beautiful and powerful, but there seems to be a lack of appreciation for the subtle and deep ways they impact language design. You have to design them in right from the beginning; it's a tricky thing thing to get right, and doing so absolutely requires flow typing.

Sum types are often used in cases where the type is unknown at run time. In C++ the analog would be std::variant. In Rust it would be enums. In Haskell its algebraic data types.

A first class sum type in c++ ala Rust or Haskell would certainly be appreciated, as the clunkiness of std::variant/std::visit is a well known annoyance.

Could you expand on your first sentence? I don't understand what do you mean that sum types are used when the type is unknown at runtime.

They meant unknown at compile-time, not run-time.