Skip to content

Type assertions change type inference #31435

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
bowenni opened this issue May 16, 2019 · 1 comment
Closed

Type assertions change type inference #31435

bowenni opened this issue May 16, 2019 · 1 comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@bowenni
Copy link

bowenni commented May 16, 2019

TypeScript Version: It is reproducible in 3.4.5 and 3.5.0-dev.20190515 but works in 3.3.3333.

Search Terms:
type assertion, type inference

Code

declare const foo: Object;
declare function f<V = any, R = any>(p: {[key: string]: V}): V|R;
f(foo);            // mouse over f, its type is f<any,any>
f(foo) as string;  // mouse over f, its type is f<string,string>

Expected behavior:
No errors.

Actual behavior:

Argument of type 'Object' is not assignable to parameter of type '{ [key: string]: string; }'.
 f(foo) as string;  // mouse over f, its type is f<string,string>
   ~~~

It seems like the as string type assertion changes the type inference of V and R, which is quite surprising. Is this a regression or intended?

Playground Link:
https://www.typescriptlang.org/play/#src=declare%20const%20foo%3A%20Object%3B%0D%0Adeclare%20function%20f%3CV%20%3D%20any%2C%20R%20%3D%20any%3E(p%3A%20%7B%5Bkey%3A%20string%5D%3A%20V%7D)%3A%20V%7CR%3B%0D%0Af(foo)%3B%20%20%20%20%20%20%20%20%20%20%20%20%2F%2F%20f%20is%20f%3Cany%2Cany%3E%0D%0Af(foo)%20as%20string%3B%20%20%2F%2F%20f%20is%20f%3Cstring%2Cstring%3E

Related Issues:
I found #28816 (comment) which gives me a hint that TypeScript might determine the type of a type parameter in some order of preference too, similar to a parameter.
My guess is that the as string type assertion provides the contextual generic type, which is before the initializer type any but what do I know.

@ahejlsberg
Copy link
Member

This is working as intended. The type assertion establishes a contextual type and we infer from that type to the return type of the function.

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

2 participants