Iterating over keys of a union type and adding a union loses the original union type

[vkarpov15]

Bug Report

🔎 Search Terms

union type key iterate

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about keys and union tpyes

⏯ Playground Link

Playground link with relevant code

💻 Code

export interface PlayerCooldown {
  id: string;
  for: "player";
  playerId: string;
}
export interface TeamCooldown {
  id: string;
  for: "team";
  teamId: string;
}
export type Cooldown = PlayerCooldown | TeamCooldown;

type FilterQuery<T> = {
  // Remove "| number" and the script compiles fine. Error occurs with other types, like "| RegExp"
  [P in keyof T]?: T[P] | number;
};

async function test() {
   let forWho: "team" | "player" = "team";
   await getCooldownFromId(forWho, 'test');
}

async function getCooldownFromId(forWho: "team" | "player", cooldownId: string): Promise <undefined> {
    let _forWho: "player" | "team" = forWho;
    let q: FilterQuery<Cooldown> = { for: _forWho, id: cooldownId };
    return undefined;
}

test();

🙁 Actual behavior

Below error:

Type '{ for: "player" | "team"; id: string; }' is not assignable to type 'FilterQuery<Cooldown>'.
  Type '{ for: "player" | "team"; id: string; }' is not assignable to type 'FilterQuery<TeamCooldown>'.
    Types of property 'for' are incompatible.
      Type '"player" | "team"' is not assignable to type 'number | "team" | undefined'.
        Type '"player"' is not assignable to type 'number | "team" | undefined'.

🙂 Expected behavior

No compiler error. This compiles fine without the | number, adding an extra union type shouldn't break this.

[andrewbranch]

Investigation notes: in TS 3.3, removing the | number does not remove the error. The current behavior is consistent from 3.5 on, and 3.4 is not supported by the playground so I didn’t try it. If you remove | number, FilterQuery<T> is just Partial<T>, and I’m guessing there was a targeted fix for Partial mapped types that removed the error, perhaps #30112 which fits the time frame.

[tooxoot]

I ran into the same problem while using the mongodb package.
To better understand the issue I wrote the following (hopefully) less convoluted example:

type UnionTypeA = { type: 'A' };
type UnionTypeB = { type: 'B' };
type SomeUnion = UnionTypeA | UnionTypeB;

type failingGeneric<T> = {
  [P in keyof T]: number | T[P];
};

// failing for union assignment
const t2: 'A' | 'B' = undefined as any;
const fails_I: failingGeneric<SomeUnion> = {
  type: t2,
};

// works for non union assignment
const t1: 'B' = undefined as any;
const works_I: failingGeneric<SomeUnion> = {
  type: t1,
};

// works if number is ommitted
type workingGeneric<T> = {
  [P in keyof T]: T[P];
};
const works_II: workingGeneric<SomeUnion> = {
  type: t1,
};

⇒ playground

It seems that number | T[P]; is handled like either be number | 'A' or number | 'B' instead of ``number | 'A' | 'B'.

[RyanCavanaugh]

@tooxoot thanks for the simpler repro; this makes the problem more apparent

In general an assignment from T<U | V> to T<U> | T<V> is not allowable, because e.g. for T<S> = { x: S, y: S } an instantiation like { x: string | number, y: string | number } is not either of { x: string, y: string } | { x: number, y: number } since a legal value is { x: "a", y: 0 }. Rejecting assignments like these is always sound, but sometimes incomplete.

For performance reasons, it's inadvisable to recover this completeness by expanding T<U | V> into its possible structural inhabitants, because for all but the very most trivial types, this is combinatorially explosive (including potentially infinite). The one counterexample is when you have a discriminant property -- a union of literals. In this case, we can be reasonably sure that there's a small and finite number of inhabitants to check. If the number of possibilities turns out to be 25 or less, we go ahead and enumerate them.

However, when we add number to the target, it ceases to be considered a discriminant, and none of this logic fires, and the assignment is rejected.

The comments in typeRelatedToDiscriminatedType in checker.ts outline this logic in more detail.

[tooxoot]

Thanks @RyanCavanaugh for the detailed explanation.
I should have finished my computer science degree... 😅
Non the less I can grasp that an assignment from T<U | V> to T<U> | T<V> only is resolvable for somewhat favourable cases.

What I still don't get is why in my example the failingGeneric<SomeUnion> is apparently treated as {type: number | 'A'} | {type: number | 'B'} instead of as{ type: number | 'A' | 'B' }?

[RyanCavanaugh]

Unions distribute in this case, so failingGeneric<SomeUnion> is the union failingGeneric<UnionTypeA> | failingGeneric<UnionTypeB>. When an assignment to a union T | U | V | ... fails, we don't want to show you every possible failure (since any single failure is sufficient to block the assignment), so we pick one mostly arbitrarily (there are some heuristics to pick "the one you probably meant", but none apply here) and show that.

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.