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

TypeScript does not infer equivalence of generic type arguments, TS2322 for equivalent types #35679

Closed
thomaslaich opened this issue Dec 14, 2019 · 2 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@thomaslaich
Copy link

thomaslaich commented Dec 14, 2019

TypeScript Version: 3.7.2 or nightly

Search Terms: generic constrained type parameter error, error TS2322

Code: Consider the following example:

function myFunc<TProps extends { foo: any }>(props: TProps) {
    type NewType = Omit<TProps & { state: any }, "state">;
    /* declare */ const nt: NewType = 0 as any;
    const test: TProps = props;
    const test2: TProps = nt; // error
}

Actual behaviour: This yields the following error message on the line where I try to assign nt to test2:

Type 'Pick<TProps & { state: any; }, Exclude<keyof TProps, "state">>' is not assignable to type 'TProps'.
  'Pick<TProps & { state: any; }, Exclude<keyof TProps, "state">>' is assignable to the constraint of type 'TProps', but 'TProps' could be instantiated with a different subtype of constraint '{ foo: any; }'.(2322)

Expected behaviour: Should have no error.

Background: This error message is correctly shown on something like this:

function fn1<T extends string>(x: T): T {
  return "hello world!";
}

However, in the above example NewType should be the same as TProps no matter how TProps is instantiated.

Playground Link: TS Playground

Related issues:
#29049

@fatcerberus
Copy link

TProps might have a state property. NewType definitely doesn’t (because you’ve Omitted it).

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Dec 20, 2019
@RyanCavanaugh
Copy link
Member

Some day we will write an error message that convinces people these errors are correct 😢

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

3 participants