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

noImplicitAny and generic arrow functions misbehave #13632

Closed
zerkms opened this issue Jan 23, 2017 · 4 comments
Closed

noImplicitAny and generic arrow functions misbehave #13632

zerkms opened this issue Jan 23, 2017 · 4 comments
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed

Comments

@zerkms
Copy link

zerkms commented Jan 23, 2017

TypeScript Version: playground (2.1.4-insiders.20161201)

Code

The following code should be run with the noImplicitAny set:

let f1: <T>(a: T) => T = a => a;

function f2<T>(a: T): T {
    return a;
};

Expected behavior:

Both functions should compile fine.

Actual behavior:

The f1 arrow function fails the type check as the compiler thinks a is of any type.

@mhegazy
Copy link
Contributor

mhegazy commented Jan 23, 2017

When the compiler compares any generic signature, it erases the generic type parameters, and replaces them with any. the result is that the parameter on the right hand-side here gets a type any implicitly. the error is telling you that this has happened.

If the compiler gets "smarter" comparing generic signatures, the error would go away.

@mhegazy mhegazy added the Design Limitation Constraints of the existing architecture prevent this from being fixed label Jan 23, 2017
@zpdDG4gta8XKpMCd
Copy link

If the compiler gets "smarter" comparing generic signatures, the error would go away.

what are the chances?

@mhegazy mhegazy closed this as completed Apr 21, 2017
@zerkms
Copy link
Author

zerkms commented Apr 22, 2017

@mhegazy what is the final resolution?

@mhegazy
Copy link
Contributor

mhegazy commented May 18, 2017

@mhegazy what is the final resolution?

resolutions, just like types, are always open in TS :D

Should be tracked under #9366

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed
Projects
None yet
Development

No branches or pull requests

3 participants