Repository navigation
Conditional type evaluation of type aliases produces different result than their equivalent substitution #48070
Description
Bug Report
🔎 Search Terms
extends
🕗 Version & Regression Information
v4.5.4
⏯ Playground Link
Playground link with relevant code
💻 Code
type S<X> = <T>() => T extends X ? 1 : '2'
type Foo = S<'s1'>
type Foo2 = S<'s2'>
type Result1 = Foo extends Foo2 ? true : false
type Result2 = S<'s1'> extends S<'s2'> ? true : false🙁 Actual behavior
For the result2 expression, the only difference from result1 is that result1 uses the type rather than the specific S<'s1'> ,But they returned a completely different result. Result1 return true,Result2 return false
🙂 Expected behavior
type Result1 and type Result2 should return false
Activity
jcalz commentedon Mar 1, 2022
Version/regression info: behavior changed between 4.2.0-dev.20210111 and 4.2.0-dev.20210112
jcalz commentedon Mar 1, 2022
Looks like #42284 may be the cause, and therefore this is possibly a duplicate of #42421, #44119 (and so maybe #29698 in turn?), etc. Those are listed as "working as intended" (although it seems more like "design limitation" to me, but 🤷♂️).
Okay, that's enough amateur sleuthing for me. Hopefully it helps the real TS squad with their triage. 👦🕵️♂️
RyanCavanaugh commentedon Mar 1, 2022
Anders Hejlsberg (@ahejlsberg) mentioned yesterday he was looking into variance computation, and this seems relevant...
[-]extends bug[/-][+]Conditional type evaluation of type aliases produces different result than their equivalent substitution[/+]ahejlsberg commentedon Mar 2, 2022
Yeah, there's an issue here. When relating two signatures that were instantiated from the same origin we erase type parameters as they're known to be the same. Since erasure substitutes
anyfor the type parameters, it causes us to resolve the conditional types in the example where really they should stay deferred. I think the fix is to unify the signatures (by instantiating one with the type parameters of the other) instead of erasing their type parameters.ddurschlag commentedon Oct 6, 2023
Not sure if this is a separate bug (happy to file it -- maybe Anders Hejlsberg (@ahejlsberg) can comment?) or just an even worse variation of this one.
Not only does going through the IsItNumber alias change the output, it somehow ends up with
neveras the result.whzx5byb commentedon Oct 7, 2023
ddurschlag I think this is because
string & numberis eagerly reduced toneverwhen used as a generic type parameter.ddurschlag commentedon Oct 7, 2023
This seems right. Avoiding primitive types produces more sensible results:
I find this combination of sometimes-eager/sometimes-lazy type evaluation difficult to work with. Why is string&number not eagerly reduced in general? Why are some conditional types eagerly evaluated, and some lazily so? At this point, I want a VSCode plugin that shows what TS thinks of my code internally (e.g. which type expressions are eager, which are lazy, which prevent tail recursive evaluation of conditional types, which are having their type parameters erased...). Even worse, I might want the ability to turn off certain eager evaluation optimizations per-line :(
ahejlsberg commentedon Oct 7, 2023
ddurschlag The difference is that the conditional type in
IsItNumber<X>is a distributive conditional type, whereas the conditional type inUnsurprisinglyTrueis not. Distributive conditional types are distributed over union types when instantiated, and sinceneveris the empty union type, a distributive conditional type applied toneveralways producesnever.ehmicky commentedon Jan 15, 2024
I have opened a duplicate issue at #57062 that I am closing in favor of this issue.
However, just for information, this is the code sample. It produces the same problem as above, but slightly differently.
Playground link.
In that code, the following works around the problem:
Another workaround:
bergwerf commentedon Mar 22, 2025
I encountered another instance of this issue:
The logic behind evaluating the type expression to
numberis mysterious to me. It implies thatnumber | number[] extends numberis ambiguous..jcalz commentedon Mar 22, 2025
No, that's just a distributive conditional type, which depends on whether the
Tyou're checking is generic or not. You gave the nameTto both a generic type parameter and a specific type, but they are different things and behave differently in conditional types. This is intended behavior and not an instance of a bug.