The answer to this inquiry may revolve around a corrective measure implemented in TypeScript 3.3. The articulation of the revised approach for evaluating conditional types is as follows:
When handling a conditional type T extends U ? X : Y
, the decision-making process for deferring resolution of a conditional type adheres to the following algorithm:
- If
T
is not assignable to U
(taking all related type parameters of T
and U
into account), we resolve to Y
(indicating that T
indeed cannot be assigned to U
),
- If
T
is assignable to U
(considering all unrelated type parameters of T
and U
), we settle on X
(signifying that T
can be unequivocally assigned to U
),
- If neither condition is met, we postpone resolution.
Hence, it appears that keyof T extends keyof T ? 1 : 0
gets deferred because keyof T1
cannot be assigned to keyof T2
if T1
and T2
are disparate types. While this deferral isn't inherently incorrect, it does seem like a limitation.
In fact, by conducting a test using TS 3.2.1 (link here), your code resolves eagerly, indicating that this was an alteration introduced with TS3.3.
An intriguing aspect is that the bug fix's algorithmic description seems applicable to your workaround as well. It remains unclear why [keyof T] extends [keyof T]
would alter anything since [keyof T1]
isn't definitively assignable to [keyof T2]</code when <code>T1
and T2
are unrelated. There still lies some enigma here; unfortunately, I haven't been able to unravel it yet, so I might just concede defeat at this point. Oh well!
Additionally, there has been a specific instance reported where X extends X ? 1 : 0
doesn't resolve promptly (and encasing it in a one-tuple seemingly "resolves" the issue). This concern was classified as a bug, hinting at a potential future resolution.
Hopefully, this information proves beneficial to you; best of luck!