Regression: Generic function returning union of tuples is not assignable to identical type since v4.2 #63019

Activity

1. mkantor commented on Jan 20, 2026

   

   Matt Kantor (mkantor)

   on Jan 20, 2026

   Contributor

   More actions

   Just a note: you mentioned that the behavior changed in v4.2, but it seems only the object-type-returning version changed. The tuple version has an error as far back as v3.3.

   Some playgrounds to demonstrate:

   • 4.2
   • 4.1
   • 3.3
2. RyanCavanaugh commented on Jan 20, 2026

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Jan 20, 2026

   Member

   More actions

   🤖 Thank you for your issue! I've done some analysis to help get you started. This response is automatically generated; feel free to 👍 or 👎 this comment according to its usefulness.

   Similar Issues

   Here are the most similar issues I found

   • (71%) microsoft/typescript#43904: [TS 4.2] Narrowing a union type is inconsistent using type guards on different member of union
   • (70%) microsoft/typescript#43098: Regression on assignability of generics
   • (70%) microsoft/typescript#51180: Type confusion when function returns a union
   • (70%) microsoft/typescript#49893: Incorrect type inference of common generic method over union type
   • (70%) microsoft/typescript#44093: Regression: Rest parameter typed as union of tuple types behaves differently in 4.3
   • (70%) microsoft/typescript#44891: Incorrect widening (constraint fallback?) during inference when union with `undefined` appears in constraint
   • (70%) microsoft/typescript#1011: Mixing tuple & generics
   • (69%) microsoft/typescript#42935: Regression with unions introduced in typescript 4.2
   • (69%) microsoft/typescript#21185: Spurious "A type predicate's type must be assignable to its parameter's type"
   • (69%) microsoft/typescript#44315: Generic function does not accept argument of type with union and intersection
   • (69%) microsoft/typescript#36053: Returned tuples don't match compatible types when using function union types
   • (69%) microsoft/typescript#43185: Type loosening regression with union types in TS 4.2
   • (69%) microsoft/typescript#58603: Type union not matched starting from TS 5.1
   • (69%) microsoft/typescript#44095: Alias type for indexing a generic object with with transform breaking change in 4.2+ (2nd issue)
   • (68%) microsoft/typescript#59108: Regression in types after v5.5

   If your issue is a duplicate of one of these, feel free to close this issue. Otherwise, no action is needed.

   Possibly Working as Intended

   It looks like this behavior might be intentional. Here's what a computer had to say about it.

   ReadA is not actually a subtype of ReadB once you apply the rules for higher-order generic functions.

   When one generic function type is assigned to another, the target function gets to pick the type argument. Whatever the target picks has to work for every call to the source function. Formally, the checker verifies that for all choices of R supplied by the context, the source’s return type is compatible with the target’s.

   In ReadB, the caller is allowed to choose an R that definitely does not contain undefined – for example string.

   const b: ReadB = …;
   const [done, value] = b<string>();    // value: string (cannot be undefined)
   

   So any value that is considered assignable to ReadB must guarantee that, whenever the caller picks such an R, the tuple [false, R] never contains undefined.

   A value of type ReadA does not have to give that guarantee. Because the same type parameter R is also used in the [true, R | undefined] branch, an implementation can satisfy ReadA in a way that allows undefined to flow into the false branch (for instance by writing return [false, undefined as any] and relying on any). That would violate the promise ReadB makes to its callers.

   Starting with 4.2 the checker became stricter about this scenario to close that soundness hole, so the earlier “working” behavior was actually unsound. The current error is therefore correct.

   🚀React with 🚀1Reacted by snarbles2
3. mkantor commented on Jan 20, 2026

   

   Matt Kantor (mkantor)

   on Jan 20, 2026

   Contributor

   More actions

   I don't think the AI explanation in the previous comment makes sense (otherwise ReadA should also not be a subtype of itself, and the "for instance" example with the type assertion could be used to argue that no type should ever be a subtype of any other type).

   Anyway, I also noticed that code like this has no type errors:

   type Example<R> = [false, R] | [true, R | undefined];
   type ReadA = <R>() => Example<R>;
   type ReadB = <R>() => Example<R>;
   
   const test = (_: ReadA): ReadB => _;

   That's semantically identical to the example from the issue description, just with the return type factored out into a type alias.
4. Andarist commented on Jan 20, 2026

   

   Mateusz Burzyński (Andarist)

   on Jan 20, 2026

   Contributor

   More actions

   Matt Kantor (@mkantor) that's most likely because the inference can match up the type alias on the source and target sides and just infer between its type arguments (without infering from its structure). So it can easily infer between both Rs directly (when relating generic signatures like this the inference happens between thosse signatures).

   Without that, unfortunately inference manages to infer from [true, R | undefined] source into [false, R] target, resulting with inferring R | undefined into R. I suspect that creates the issue later on - given that inference has ReturnType priority and that implies combination of gathered candidates (the final inferred candidate becomes the union of all gathered candidates). This part of this theory seems to be confirmed by the fact this works fine:

   type A = <R>(arg: [false, R] | [true, R | undefined]) => void;
   type B = <R>(arg: [false, R] | [true, R | undefined]) => void;
   
   const test = (_: A): B => _;

   Overall, my educated guess is that the problem is that inferToMultipleTypes can't match up discriminated unions like this to infer between "matching" types.
5. Ryan Cavanaugh (RyanCavanaugh)

   added

   Help WantedYou can do thisYou can do this

   Possible ImprovementThe current behavior isn't wrong, but it's possible to see that it might be better in some casesThe current behavior isn't wrong, but it's possible to see that it might be better in some cases

   on Feb 3, 2026
6. Ryan Cavanaugh (RyanCavanaugh)

   added this to the Backlog milestone on Feb 3, 2026
7. Ryan Cavanaugh (RyanCavanaugh)

   added

   Domain: check: Type InferenceRelated to type inference performed during signature resolution or `infer` type resolutionRelated to type inference performed during signature resolution or `infer` type resolution

   on Feb 3, 2026
8. Ichi075 commented on Sep 13, 2026

   

   Ichinose_ (Ichi075)

   on Sep 13, 2026

   More actions

   I'd like to investigate whether the inference behavior can be improved
   without weakening type safety.

   The issue seems related to inference across the discriminated union:
   the source and target branches with the same discriminant may not be
   matched before inferring R, causing R | undefined to leak into the [false, R] branch.

   The equivalent version using a type alias works, so I plan to investigate
   whether the union members can be matched by their discriminant during
   inference. Is this direction reasonable?

   I also noticed that the tuple version reproduces as far back as TypeScript
   3.3, while the object version appears to have changed in 4.2.