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

noUncheckedIndexAccess behavior with for...in loops with a constant #45169

Closed
charles-toller opened this issue Jul 23, 2021 · 2 comments
Closed
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@charles-toller
Copy link

Bug Report

Using a for...in loop with a constant key variable errors with noUncheckedIndexAccess.

🔎 Search Terms

for...in
noUncheckedIndexAccess
for(const in)

🕗 Version & Regression Information

Seen in v4.1.5 (oldest playground with noUncheckedIndexAccess) and next (v4.4.0-dev.20210723 at time of writing)

⏯ Playground Link

Playground link with relevant code

💻 Code

type A = {[key: string]: number};
declare var a: A;
for (const key in a) {
    const value: number = a[key];
}

🙁 Actual behavior

Error:

Type 'number | undefined' is not assignable to type 'number'.
  Type 'undefined' is not assignable to type 'number'.(2322)

🙂 Expected behavior

No error, key is in object by the for...in loop and clearly isn't modified as variable is const

@RyanCavanaugh
Copy link
Member

RyanCavanaugh commented Jul 23, 2021

This is the documented behavior of the flag; see #39560. It's entirely possible to read an undefined out of this loop if mutation were to occur to the object prior to the read.

@andrewbranch andrewbranch added the Working as Intended The behavior described is the intended behavior; this is not a bug label Jul 26, 2021
@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