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
Conditional types are evaluated too eagerly #34810
Search Terms: conditional type eager, conditional type narrowing
Code
typeFooHelper<X>=(arg1: X,arg2: Xextends0 ? number : string)=>void;typeFoo=FooHelper<0|1>;letx: number;constfoo: Foo=(t,d)=>{if(t===0){x=d;}}
Expected behavior:
No errors, t has type 0 | 1 in the function body which gets narrowed to just 0 in the body of the if statement. In the if statement, d should have type number, because we know that t has to have type 0.
Actual behavior:
Type 'string | number' is not assignable to type 'string'.
If I understand correctly, your intention is kind of like the following: the parameter arg2 is dependent on the type of arg1. Actually, it is dependent on the value of arg1, but that is inexpressible.
Meaning: the value of arg1 can be 0, while the type variable X can be instantiated with 0 | 1, which means that arg2 can actually hold a string. As a result the logic of narrowing X to 0 based on the check arg1 === 0 is unsound.
We would additionally require something like #30284 to solve this.
Activity
jvanbruegge commentedon Oct 29, 2019
I also tried to define Foo differently:
But that infers
tanddboth as anyRyanCavanaugh commentedon Oct 29, 2019
Fooisn't a generic type, so the conditional has already been evaluated. Conditional types only stay unresolved when they're in a generic type.jvanbruegge commentedon Oct 29, 2019
So is it somehow possible to get the wanted behavior?
RyanCavanaugh commentedon Oct 29, 2019
Not really, no. You'd need #33014 at an absolute minimum - there's currently no mechanism that would allow for the kind of narrowing implied here.
jvanbruegge commentedon Oct 29, 2019
Sad. Ok, thank you
rubenpieters commentedon Nov 2, 2019
If I understand correctly, your intention is kind of like the following: the parameter
arg2is dependent on the type ofarg1. Actually, it is dependent on the value ofarg1, but that is inexpressible.Unfortunately, just #33014 won't solve your problem (it is similar to the rejected case
ahere). Since the following can happen:Meaning: the value of
arg1can be0, while the type variableXcan be instantiated with0 | 1, which means thatarg2can actually hold astring. As a result the logic of narrowingXto0based on the checkarg1 === 0is unsound.We would additionally require something like #30284 to solve this.