Generics narrowing not considering constraints when conditional is involved

[Tiedye]

Bug Report Feature Request?

🔎 Search Terms

generics conditional types narrowing

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about Generics, Type System Behavior

⏯ Playground Link

Playground link with relevant code

💻 Code

interface State {
    a: string;
    b: { value: string};
    c: { value: string};
}
type NestedKey = "b" | "c";

type A<T> = T;

function f<T extends keyof State>(key: T, v: A<State[T]>) {
}

type B<T> = T extends object ? T : never;

function g<T extends keyof State>(key: T, v: B<State[T]>) {
}

// this works

function ex1<T extends NestedKey>(key: T) {
    f(key, {value: ''});
}

// this doesn't

function ex2<T extends NestedKey>(key: T) {
    g(key, {value: ''}); // this should not throw an error but it does
}

🙁 Actual behavior

It seems when a conditional type is used, the compiler isn't evaluating the constraint of the given type parameter and instead falling back to the constraint defined locally.

🙂 Expected behavior

The arguments type should be narrowed using the most constrained generic regardless of conditional types

[MartinJohns]

It's a design limitation. The type of B<State[T]> can't be resolved, because the type of T is not known.

[RyanCavanaugh]

I don't think there's a sound way to compute the constraint-lookup interaction in the presence of arbitrary conditional types. B is effectively the same as the much more readily-reasoned-about B & object so I would use that instead.

[Tiedye]

I don't think there's a sound way to compute the constraint-lookup interaction in the presence of arbitrary conditional types. B is effectively the same as the much more readily-reasoned-about B & object so I would use that instead.

In the use case in my app that is not possible. Ex: playground

Whats the difference between a conditional and not conditional type in this case? For the non conditional type it seems to be resolving it just fine

[Tiedye]

It's a design limitation. The type of B<State[T]> can't be resolved, because the type of T is not known.

Would it be possible to use the NestedKey type here?

[github-actions]

This issue has been marked as 'Not a Defect' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[Tiedye]

Hope ts can do this one day!