Support open-ended unions

Suggestion

Ability to discriminate between union members when not all union members are known.

Use Cases

• redux actions: See https://github.com/Microsoft/TypeScript/issues/2214#issuecomment-352103680
• This would enable us to discriminate on Node kinds without converting Node to a huge union (which slows down compilation too much). (Also, Node is effectively open-ended because we add new kinds fairly often.)

Examples

interface Shape {
    unique kind: string;
}

interface Square extends Shape {
    kind: "square";
    size: number;
}

interface Circle extends Shape {
    kind: "circle";
    radius: number;
}

// other shapes may exist

function area(s: Shape) {
    switch (s.kind) {
        case "square":
            return s.size * s.size;
        case "circle":
            return Math.PI * s.radius ** 2;
        default:
            return 0; // Or hand off to some other function that handles other Shape kinds
    }
}

Checklist

My suggestion meets these guidelines:

• This wouldn’t be a breaking change in existing TypeScript / JavaScript code
• This wouldn’t change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn’t a runtime feature (e.g. new expression-level syntax)

Workarounds

Cast the general type to a union of known type.

function area(sIn: Shape) {
    const s = sIn as Square | Circle;
    ...

[DanielRosenwasser]

Something like this seems to come up quite a lot with string literals. We’ll often get a request to support N well-known strings, but in reality, the system allows arbitrary strings. Usually the intent there is that tooling should give auto-complete hints, but the type-checker should not error.

This seems to be the case in #42134.

Additionally, I’ve spoken to @bterlson and @jonathandturner about this a couple of times now on the Azure SDK. The work-arounds are

• Using keyof { well: any, known: any, fields: any, [x: string]: any } where tooling picks up on well-known properties from keyof for completions, but the effective type is just string. (ugh)
• string | SomeEnumType (less ugh), or just string with some documented enum to users can pass through.

[RyanCavanaugh]

Open questions here:

• What (if anything) prevents the declaration of two things with the same kind ?
• How does this work in a “pull” typechecking model? To know what to do in the switch, we’d have to exhaustively check the entire program to find all possible declarations
• Where do the perf wins come from? Isn’t the type of s in the default block (if we imagine hundreds of other shapes) still an enormous union? Or does an open-ended union imply the existence of subtraction types?