-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Comments
For anyone else checking, it has nothing to do with the initializer. Playground link with 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])
} |
This is apparently by design. See #42620. I presume code existed before that PR that depends on parameters being assigned type |
Thanks for digging that up, totally forgot about it! |
This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes. |
Bug Report
🔎 Search Terms
array union types type inference noImplicitAny disabled
🕗 Version & Regression Information
This changed between versions
4.2.3
and4.3.5
, as before4.3.5
, type inference for the 2nd case inferredany
regardless of ifnoImplicitAny
was enabled. After4.3.5
, the expected inference happens whennoImplicitAny
is enabled, but behaves as it did before4.3.5
whennoImplicitAny
is not enabled.⏯ Playground Link
Playground link with relevant code
💻 Code
🙁 Actual behavior
When
noImplicitAny
is not enabled in the TS config, inferred types are impacted (inferred asany
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.The text was updated successfully, but these errors were encountered: