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

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

Suggested Changes

I'm wondering ifno-for-in-array should be deprecated in favor of a trivial syntactic ban onForInStatement in all cases.

For ordinary objects,for...in has pitfalls, too: see core ruleguard-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.

constreArray=/fe/.exec('foo')!;for(constreArrayKeyinreArray){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 offor...in makes more sense to me anyway, since there aren't any common scenarios in which you'dwantfor...in, and don't have a straightforward alternative to it.

The one argument I see against this is thatfor...inseems to be the only way to get enumerable inherited properties (EDIT: other thanmanually 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