Inconsistency involving discriminated union and flatMap

[benjaminjkraft]

The following code works in TS, but errors in Go:

export type InputOp = { op: "add" } | { op: "remove"; value?: Array<unknown> };
export type OutputOp = { op: "add" | "remove" };

export function f(operations: InputOp[]): OutputOp[] {
  return operations.flatMap((operation) => {
    if (operation.op === "remove" && operation.value) {
      return [].map(() => ({ op: "remove" }));
    } else {
      return [operation];
    }
  });
}

The error in Go is:

src/flatMap.ts:5:29 - error TS2345: Argument of type '(this: undefined, operation: InputOp) => { op: "remove"; }[] | InputOp[]' is not assignable to parameter of type '(this: undefined, value: InputOp, index: number, array: InputOp[]) => readonly { op: "remove"; }[] | { op: "remove"; }'.
  Type '{ op: "remove"; }[] | InputOp[]' is not assignable to type 'readonly { op: "remove"; }[] | { op: "remove"; }'.
    Type 'InputOp[]' is not assignable to type 'readonly { op: "remove"; }[] | { op: "remove"; }'.
      Type 'InputOp[]' is not assignable to type 'readonly { op: "remove"; }[]'.
        Type 'InputOp' is not assignable to type '{ op: "remove"; }'.
          Type '{ op: "add"; }' is not assignable to type '{ op: "remove"; }'.
            Types of property 'op' are incompatible.
              Type '"add"' is not assignable to type '"remove"'.

5   return operations.flatMap((operation) => {
                              ~~~~~~~~~~~~~~~~

The example is seemingly quite close to minimal: removing the && operation.value, replacing the first case with [{ op: "remove" }], removing either case, replacing flatMap with map, or adding more explicit annotations, all either make TS error or make Go pass. I guess there's some complicated interaction of how Go is inferring the type of the callback when narrowing? Or maybe those things all let the inference happen some other way that works better, avoiding the problematic case.

(This is simplified from some real code which is a bit more complex, of course it doesn't make sense as-is.)

[ahejlsberg]

This is yet another example of effects of type ordering. In the call to flatMap, we make two inferences for the return type of the arrow expression argument, { op: "remove"}[] and InputOp[]. Neither is a strict supertype of the other, so inference picks the first of the two candidates. But due to differences in ordering of union type constituents, the two compilers discover the candidates in opposite order and so pick different candidates. And since { op: "remove" } is assignable to InputOp but not vice-versa, the types work out only when the chosen candidate is InputOp.

We could potentially do a bit better here by using assignability as the tiebreaker when there is no strict supertype winner. Meanwhile, the easy fix is to include a type assertion in the call to map:

return [].map(() => ({ op: "remove" } as InputOp));

[jakebailey]

The above suggestion causes just one break: #63328 (comment)

[RyanCavanaugh]

The linked PR didn't correctly implement the proposal