Skip to content

noImplicitAny ignored on generic type resolution #33279

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
markoknez opened this issue Sep 6, 2019 · 2 comments
Closed

noImplicitAny ignored on generic type resolution #33279

markoknez opened this issue Sep 6, 2019 · 2 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@markoknez
Copy link

TypeScript Version: 3.6.2

Search Terms:
noImplicitAny generic

Code

class Test<T> {
    options: Map<T, string> = new Map()
    constructor(options: Map<T, string>) {
        
    }
}

let t = new Test(new Map())
t.options.set("a", "abc")
t.options.set(123, "abc")

Expected behavior:
When using strict / noImplicityAny I would expect that T which implicitly became any would be reported as an error.

Actual behavior:
No error thrown, T becomes of type any.

Playground Link:
https://www.typescriptlang.org/play/index.html?target=6#code/MYGwhgzhAEAqCmEAuAeWA+aBvAUNf0A9gA5ICWhAdhAFzQCyYxaANNMgE5mUDmmAvNErwA7gyYAKAJR4CwKpwCuwJIQ4SS5BXUbNYbTtz5TssggTPQAvjhs4Q8JNCeDhYhMglvxxaTKQAdJoU1AEQjhIARGCRbNEARsCR-kGkIRBhEQCMAEwAzHFgiclAA

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

This doesn't fit the criteria of an "implicit any". Map explicitly has a construct signature that returns Map<any, any>, and that first any was an explicit inference candidate for Test<T>'s T.

Relevant discussion at #24737

@typescript-bot
Copy link
Collaborator

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

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