Skip to content

Having noImplicitAny Not Enabled Impacts Type Inference #47294

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
joealden opened this issue Jan 3, 2022 · 4 comments
Closed

Having noImplicitAny Not Enabled Impacts Type Inference #47294

joealden opened this issue Jan 3, 2022 · 4 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@joealden
Copy link

joealden commented Jan 3, 2022

Bug Report

🔎 Search Terms

array union types type inference noImplicitAny disabled

🕗 Version & Regression Information

This changed between versions 4.2.3 and 4.3.5, as before 4.3.5, type inference for the 2nd case inferred any regardless of if noImplicitAny was enabled. After 4.3.5, the expected inference happens when noImplicitAny is enabled, but behaves as it did before 4.3.5 when noImplicitAny is not enabled.

⏯ Playground Link

Playground link with relevant code

💻 Code

// `item` and `key` are both typed as expected (`string | number` and `number` respectively)
const array1: Array<string | number> = [];
const mapped1 = array1.map((item, key) => [item, key])

// `item` and `key` are both typed as `any`
const array2: Array<string> | Array<number> = [];
const mapped2 = array2.map((item, key) => [item, key])

🙁 Actual behavior

When noImplicitAny is not enabled in the TS config, inferred types are impacted (inferred as any in the above case).

🙂 Expected behavior

noImplicitAny shouldn't impact inferred types, or if this is expected behaviour as having this option enabled allows for better heuristics to work, then I think having it documented that this settings isn't essentially just a "lint rule" might be a good idea.

@DanielRosenwasser DanielRosenwasser added the Needs Investigation This issue needs a team member to investigate its status. label Jan 6, 2022
@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Jan 6, 2022

For anyone else checking, it has nothing to do with the initializer.

Playground link with noImplicitAny disabled

function foo1(fnArray1: Array<string | number>) {
    // `item` and `key` are both typed as expected (`string | number` and `number`)
    const mapped1 = fnArray1.map((item, key) => [item, key])
}

function foo2(fnArray2: Array<string> | Array<number>) {
    // `item` and `key` are both typed as `any`
    const mapped2 = fnArray2.map((item, key) => [item, key])
}

@ahejlsberg
Copy link
Member

This is apparently by design. See #42620. I presume code existed before that PR that depends on parameters being assigned type any when -noImplicitAny is disabled.

@ahejlsberg ahejlsberg added Working as Intended The behavior described is the intended behavior; this is not a bug and removed Needs Investigation This issue needs a team member to investigate its status. labels Jan 11, 2022
@DanielRosenwasser
Copy link
Member

Thanks for digging that up, totally forgot about it!

@ahejlsberg ahejlsberg removed their assignment Jan 13, 2022
@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

4 participants