Repository navigation
Type parameter not usable as type argument in identical type; union in constraint becomes intersectionΒ #60892
Description
Activity
FWIW, both come from
distributeIndexOverObjectType- the union/intersection output is determined based on thewritingoption. When doing the relationship check the compiler checks ifUis assignable to the constraint of the target type parameter - that's(T | { x: "a"; })["x"]. So far so good. But then it's normalized/simplified close to the top ofisRelatedTo(using transitively mentioneddistributeIndexOverObjectType) and the output of that is an intersection. At this stage, the source itself is stillU- but later on its constraint goes through the same normalization... this time it becomes a union. But at this stage, the target is already heavily disassociated from its origin anyway. I suspect that if this indexed access on the target side would stay deferred then it would just work but implementing that might prove tricky.
π Search Terms
indexed access, constraints, generic, unions, ts2344
π Version & Regression Information
β― Playground Link
Playground link
π» Code
π Actual behavior
The
Utype parameter is rejected as a type argument with a TS2344 error about how it doesn't satisfy the constraint. The constraint seems to have shifted from a union to an intersection, even though it comes from an identical place.π Expected behavior
The
Utype parameter should be accepted as a type argument.Additional information about the issue
Distilled from SO question.
I expect this is a consequence of #30769 as per #31731 (comment), but it is at least somewhat surprising that this should happen when the types involved are identical. One could rewrite the constraint to
U extends T["x"] | "a", of course, but this is distilled from the above SO question which is presumably distilled from some use case. What's happening here, exactly, and is it intended, a design limitation, or a bona fide bug?