You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Nested conditional types make extends clause infer types not visible #22359
typeCond<TIn>=TInextends(infer Aextends infer TInside ? infer C : infer D) ? [A,C,D] : never;// more motivating real example:typeInvertCond<TIn>=TInextends(infer Textends infer U ? infer A : infer B) ? (TextendsU ? B : A) : TIn;
Expected behavior:
At least infer types A, C, and D should be visible within the true branch of the outer conditional type. Arguably, so should TInside, depending on how you expect scoping to work.
Actual behavior: Cannot find name "A" Cannot find name "C" Cannot find name "D"
Several reasons why this won't work. First, infer X declarations are lexically restricted to the extends type of a conditional type. This holds even when a conditional type is nested in the extends clause of an outer conditional type. I think this is a very reasonable rule. Without it it would be very non-intuitive to understand which conditional type an infer X belongs to.
Now, you could work around the lexical restriction:
typeConditional<T,U,A,B>=TextendsU ? A : B;typeInvertCond<X>=XextendsConditional<infer T, infer U, infer A, infer B> ? Conditional<T,U,B,A> : X;
But the issue you'll then face is that we defer resolution of InvertCond (because X is generic) and only resolve once we instantiate for a non-generic type argument. But at that point the "conditionalness" of the type has disappeared, so there's nothing to infer from.
Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.
Activity
ahejlsberg commentedon Mar 7, 2018
Several reasons why this won't work. First,
infer Xdeclarations are lexically restricted to theextendstype of a conditional type. This holds even when a conditional type is nested in theextendsclause of an outer conditional type. I think this is a very reasonable rule. Without it it would be very non-intuitive to understand which conditional type aninfer Xbelongs to.Now, you could work around the lexical restriction:
But the issue you'll then face is that we defer resolution of
InvertCond(becauseXis generic) and only resolve once we instantiate for a non-generic type argument. But at that point the "conditionalness" of the type has disappeared, so there's nothing to infer from.In short, fuhgettaboutit.
typescript-bot commentedon Mar 22, 2018
Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.
weswigham commentedon Mar 22, 2018
I believe this has been fixed by #22764.