Repository navigation
Incorrect generic inference with "inherited" types #53623
Description
Bug Report
🔎 Search Terms
Generics, inheritance, nested.
🕗 Version & Regression Information
All versions tested, up to 5.1.0-dev.
⏯ Playground Link
Playground link with relevant code
💻 Code
type ParentType<T extends number> = unknown;
type ChildType = ParentType<5>;
type GetT<T> = T extends ParentType<infer U> ? U : never;
type Test = GetT1<ChildType1>;🙁 Actual behavior
Type Test is equal to number rather than 5.
However, if T isn't unused in ParentType:
type ParentType<T extends number> = T;
// or
type ParentType<T extends number> = Array<T>;
...–then Test becomes 5.
🙂 Expected behavior
Test should be 5 in all cases.
Activity
fatcerberus commentedon Apr 1, 2023
Working as intended. Inference is done by working backwards structurally. If you don’t use the type parameter then TS won’t be able to recover it through inference and you’ll just get the constraint, as you see here.
I should note that from TS point of view any
ParentType<T>is also assignable to anyParentType<U>, for allTandU. This is the nature of structural typing.fatcerberus commentedon Apr 1, 2023
By analogy, you’re essentially asking TS to solve
x * 0 = 0. You can substitute any number forxand still have a valid solution.colecrouter commentedon Apr 1, 2023
I see. Is there a way to include
TinParentTypesuch that it does exist as a valid constraint? I can't think of a way to work around this, assuming thatParentTypeis actually independent ofT.From what you're saying, it seems like passing
Tup through (potentially many cascading types) and including it in the base type is the only way to do this. Is that right?fatcerberus commentedon Apr 1, 2023
If
ParentTypeis actually independent ofTthen the type parameter may as well not exist. It won’t affect the type. Think of it like the type equivalent of(x: number) => 0. Once you’ve called the function, you can’t recoverx- but it doesn’t really matter because the results are all interchangeable anyway.