Skip to content

Type inference failure on generic type with multiple optional properties #1801

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

Closed
Nemo157 opened this issue Jan 25, 2015 · 2 comments
Closed
Labels
Duplicate An existing issue was already created

Comments

@Nemo157
Copy link

Nemo157 commented Jan 25, 2015

interface Client {
    wrap<T>(interceptor: Interceptor<T>, config?: T): Client;
    typedWrap(interceptor: Interceptor<Config>, config?: Config): Client;
}

interface Interceptor<T> {
    parent(client?: Client, config?: T): Client;
}

interface Config {
    mime?: string;
    accept?: string;
}

var client: Client;
var config: Config = { mime: 'application/json' };
var mime: Interceptor<Config>;

client.wrap(mime, config);
client.wrap(mime, { mime: 'application/json' });

client.typedWrap(mime, config);
client.typedWrap(mime, { mime: 'application/json' });

with tsc version 1.4.1.0 gives

test.ts(20,1): error TS2453: The type argument for type parameter 'T' cannot be inferred from the usage. Consider specifying the type arguments explicitly.
  Type argument candidate 'Config' is not a valid type argument because it is not a supertype of candidate '{ mime: string; }'.

I can't tell exactly what's going wrong here, but it appears to be some issue at the intersection between generics and plain objects implementing interfaces. I would assume by the fact that both assigning the object to a typed variable and using a specified type in the function that Config is in fact a supertype of the candidate; this fact is just not being picked up during the type inference stage.

@Nemo157
Copy link
Author

Nemo157 commented Jan 25, 2015

And by the looks of it this may already be fixed in #1795 😄.

@ahejlsberg
Copy link
Member

Yes, #1795 does indeed fix this. It is the same problem reported in #1446.

@ahejlsberg ahejlsberg added the Duplicate An existing issue was already created label Jan 26, 2015
@microsoft microsoft locked and limited conversation to collaborators Jun 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

2 participants