Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generic function with inferred arguments accepts deleted types #41648

Closed
jwueller opened this issue Nov 23, 2020 · 2 comments
Closed

Generic function with inferred arguments accepts deleted types #41648

jwueller opened this issue Nov 23, 2020 · 2 comments
Labels
Question An issue which isn't directly actionable in code

Comments

@jwueller
Copy link

TypeScript Version: v4.2.0-dev.20201123

Code

interface NestedType<A, B extends string | number> {
    a: A;
    b: B;
}

export type ComplexType<T> = T extends NestedType<infer A, infer B>
    ? {items?: T[], someA?: A, someB?: B}
    : never;

function getItems<T>(complex: ComplexType<T>) {
    complex = {}; // not assignable (1)
    return complex.items || [];
}

Expected behavior:
I feel like I should not be able to call a function where a parameter resolves to never, and therefore (1) should not be able to fail, but maybe I am just fundamentally misunderstanding this aspect of the type system.

Additionally, I would expect the error message to expand on the incompatibility, instead of just stating it.

Actual behavior:
Assignment fails because of seemingly incompatible types. My IDE (IntelliJ IDEA) resolves this type to the following, which does not make any sense to me:

{items?: T[], someA?: A, someB?: B}
&
NestedType<A, B> // where does this come from?

Playground Link:
https://www.typescriptlang.org/play?ts=4.2.0-dev.20201123#code/JYOwLgpgTgZghgYwgAgHIQM6QCYBUCeADhADwCCANMgELIQAekI2GyWUoA5sgD7IgBXALYAjaAD5kAbwBQyecjgAuZGQDcchSJXUNAXxkyGhAPZQwyMERQBhE0MIAbBgWIlckgLzJcdRhGZWdCwIPGsSUBhoVSpI6OpxTXkAfmlgSCEMZJVcAG0AXSoMewgybJi2Eupy6gMFZBUQCAA3aA0ZGAEQBDBgExBkTggwAEkMjHdxAAoEeycGFTsHZ3pXUg8ASmkk5FnlhmRvKT01ZAB6M-4TCzgMDGBOEDgRZ2QpgEYNnahhgSgBvbzegAOnSEEyvD4BX0MiAA

@andrewbranch
Copy link
Member

The immediate reason why this fails (and why there is no elaboration of the error) is that there simply is no assignability relation for conditional types in higher order. See #26933. The second reason is that clearly ComplexType<T> can reduce to never, and when we check that the function body makes sense for possible instantiations of T, it’s sort of irrelevant whether or not you’re going to have trouble actually calling the function with that instantiation. After all, you can pass a never to a function that accepts a never, and just because this is a semantically fraught scenario doesn’t mean we can just pretend such an instantiation is not in the domain of the type parameter.

Additionally, I would expect the error message to expand on the incompatibility, instead of just stating it.

Well, the error would basically be calling out a limitation of the compiler that might change, not telling you an actual type-theoretical reason why assignability isn’t possible. Of the cases where we issue this error with no further details, some are only because the compiler doesn’t have the ability to reason about the relationship, but others would still be problematic code even if the compiler could reason about it. And we obviously can’t tell the difference between those cases; if we could, the former set would not be errors.

@andrewbranch andrewbranch added the Question An issue which isn't directly actionable in code label Nov 25, 2020
@typescript-bot
Copy link
Collaborator

This issue has been marked as 'Question' and has seen no recent activity. It has been automatically closed for house-keeping purposes. If you're still waiting on a response, questions are usually better suited to stackoverflow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Question An issue which isn't directly actionable in code
Projects
None yet
Development

No branches or pull requests

3 participants