Before You File a Documentation Request Please Confirm You Have Done The Following...

• I have looked for existing open or closed documentation requests that match my proposal.
• I have read the FAQ and my problem is not listed.

Suggested Changes

I'm wondering if no-for-in-array should be deprecated in favor of a trivial syntactic ban on ForInStatement in all cases.

For ordinary objects, for...in has pitfalls, too: see core rule guard-for-in. Object.keys() is widely supported and addresses this use case.

For ordinary arrays, i.e. for (const k in ["a", "b", "c"]) {}, the statement works just fine and iterates over the indices as expected (EDIT: *except for holes). Even though the indices are string-keyed, TS appears to have syntactic special-casing to allow indexing in this case. So the rule isn't really helping here.

For regex arrays, which are mentioned as a motivation for the rule, the rule doesn't even report.

const reArray = /fe/.exec('foo')!;
for (const reArrayKey in reArray) {
  console.log(reArray[reArrayKey])
}

Taken together, it seems like

• we're not reporting where we really should
• where we do report, it's not so clear we even need to
• therefore, we're not really making very good use of type information
• and a syntactic total ban of for...in makes more sense to me anyway, since there aren't any common scenarios in which you'd want for...in, and don't have a straightforward alternative to it.

The one argument I see against this is that for...in seems to be the only way to get enumerable inherited properties (EDIT: other than manually iterating the prototype chain). To which I'd say, if you need to do that for some reason, and know that you need to, then you probably are comfortable disabling eslint rules.

Affected URL(s)

https://typescript-eslint.io/rules/no-for-in-array/

Additional Info

No response