Discrepancies in behavior of spread of union type

[benjaminjkraft]

type State =
  | { loaded: true; type: "loader"; value: string }
  | { loaded: false; type: "loader" }
  | { type: "other" };

declare class Store {
  state: State;
  setState(state: State): void;
}

function unload(store: Store): void {
  store.setState({ ...store.state, loaded: false });
}

This passes in TS, in Go we get:

src/union.ts:12:36 - error TS2353: Object literal may only specify known properties, and 'loaded' does not exist in type '{ type: "other"; }'.

12   store.setState({ ...store.state, loaded: false });
                                      ~~~~~~

(It's a bit debatable who's philosophically more correct -- it depends on which objects are allowed to have unknown properties. But I haven't been able to construct a case that TS is okay with where the code produces an invalid value if we assume all unknown properties are allowed, so I'm guessing this is all intended behavior in TS.)

[ahejlsberg]

This is another issue related to ordering, though this time it is ordering of members, not types. When narrowing the State type by the discriminants specified in the { ...store.state, loaded: false } object literal, we proceed in the order of the properties in object literal type. In tsc this means we first narrow by the loaded property and then by the type property, whereas tsgo narrows in the opposite order. You can observe the effect by reordering the declarations. For example, moving the declaration of State to the end of the example causes the error to go away because tsgo then orders the properties the same way as tsc:

declare class Store {
  state: State;
  setState(state: State): void;
}

function unload(store: Store): void {
  store.setState({ ...store.state, loaded: false });
}

type State =
  | { loaded: true; type: "loader"; value: string }
  | { loaded: false; type: "loader" }
  | { type: "other" };

We may want to think about a smarter discrimination algorithm, but I don't think it has to be part of the porting effort.

[ahejlsberg]

I've given this some more thought. Our current discrimination algorithm is slightly too aggressive in cases where a discriminant is present only in some of the variants. Consider:

type Thing =
  | { str: "a", num: 0 }
  | { str: "b" }
  | { num: 1 }

const thing1: Thing = { str: "a", num: 0 }
const thing2: Thing = { str: "b", num: 1 } // Excess property error on 'num'
const thing3: Thing = { num: 1, str: "b" } // Excess property error on 'str'

Above, str and num are discriminants that are only present in some of the variants. Currently, when a discriminant in the source type matches the discriminant of a variant in the target type, we eliminate variants with non-matching discriminants and variants that don't contain that discriminant. Thus, in the thing2 assignment above, the str: "b" property in the source type causes both { str: "a", num: 0 } and { num: 1} to be eliminated from the target type, and we therefore report an excess property error on num. But in the thing3 assignment, the elimination happens based on num: 1 and we end up reporting a different excess property error. And neither of those excess property errors are correct. Rather, we have a source type that satisfies multiple variants in the target type.

Similarly, we report inconsistent errors in this example:

type Item =
  | { kind: "a", subkind: 0, value: string }
  | { kind: "a", subkind: 1, value: number }
  | { kind: "b" }

const item1: Item = { subkind: 1, kind: "b" } // Error, type "b" not assignable to type "a"
const item2: Item = { kind: "b", subkind: 1 } // Error, 'subkind' isn't a known property

All of the above inconsistencies are due to our discrimination algorithm removing variants even when those variants don't contain a particular discriminant. The more correct and conservative behavior would be to only eliminate variants that explicitly contain discriminants with non-matching values. With that change, we wouldn't report excess property errors in the first example, and we'd consistently report an excess property error on subkind in both assignments in the second example.

I'm going to put up a PR that implements this.