Template types don't resolve in conditional types

[benthayer]

🔎 Search Terms

conditional types, resolve, template

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about conditional types, templates

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.7.0-dev.20240825#code/C4TwDgpgBAglC8UDeAoKUCGAuKBnYATgJYB2A5igL4oqiRQBCCyaUARjvseVTXdAFkQAFXAQAPMKgQAHsAgkAJrlhQAPowB8zFFNnylKuAH4oAcgxmoOM2zM0AZgFcSAY2BEA9iSgPPnyWk5BWVYTQAKAEocADdPIkUWdFdvfCgZHCFRSEltRAt7dBkqIA

💻 Code

type A = {
  a: string
}

type B = {
  b: string
}

type MyType<T extends A | B> = 
T extends A ? 'a' : 'b'

function foo<T extends A>(): void {
  const x: MyType<T> = 'a'
  x
}

🙁 Actual behavior

Type "a" is not assignable to MyType

🙂 Expected behavior

Type "a" is assignable to MyType

Additional information about the issue

This additional snippet works as expected:

const x: MyType<A1> = 'a'
x

type A1 = {
  a: string
  a1: string
}

[MartinJohns]

Duplicate of #56045 / #31096.

[benthayer]

Hi, I took a look at the other issues and I'm a bit confused. Why would it make sense for the type to resolve when it's a type but not when it's a generic?

[MartinJohns]

Because the compiler does not know what type T actually is, so it can't resolve the conditional type. Constraints are not taken into consideration.

[benthayer]

Is it impossible to take the type into consideration? To me this case seems pretty clear cut that it would make sense to resolve the type, no? It's a bit weird because the generic has the same constraint that's on the type and the type is able to resolve, so I think it makes perfect sense to resolve the type in this case.

Is the problem that with types you're able to use deferred/lazy resolution and make sure that it's 100% okay whereas with the generic you don't do that because of problems with transitivity? It seems like the problems with transitivity are limited to a few specific cases. Wouldn't it be possible to compute the types in a way that avoids those problems but still let's clear cut cases like this be resolved correctly?

Regardless, this was something extremely confusing and it should probably be better documented. The error I got did nothing to point me in the right direction and the whole non-transitivity problem is definitely not something most developers are thinking about so it's unintuitive that the type constraints aren't taken into consideration

[benthayer]

Also, I appreciate you taking the time to triage/discuss this issue 🥇

[typescript-bot]

This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[MartinJohns]

Is it impossible to take the type into consideration? To me this case seems pretty clear cut that it would make sense to resolve the type, no?

I can't find the issue, but somewhere the team mentioned that it's not worth the cost, as the cases where this can be resolved are edge cases.

Also, I appreciate you taking the time to triage/discuss this issue 🥇

Please note that I am not a team member.