`noUncheckedIndexedAccess` does not narrow properly when iterating with `for...in`

[ItsHarper]

🔍 Search Terms

"noUncheckedIndexedAccess"

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

When iterating through a Record type with a for...in loop, detect that the record's key is guaranteed to be present when doing lookups on the object. If the Record does not have null or undefined keys, this will allow code to not have to handle the possibility of an undefined value when noUncheckedIndexedAccess is enabled.

⏯ Playground Link

Playground link

📃 Motivating Example

Iterating through a Record with non-null/undefined values with noUncheckedIndexedAccess enabled will no longer force handling of undefined

💻 Use Cases

Without this change, I have to either leave noUncheckedIndexAccess disabled, or add unnecessary boilerplate whenever I'm iterating through a Record.

[ItsHarper]

A similar case to this was reported as #43614, and resolved in #51653.

[jcalz]

Could you edit to talk about index signatures instead of Records? A Record<K, V> isn't required to have an index signature (e.g., Record<"a", string>).

[RyanCavanaugh]

You could still write

const arr = [1, 2, 3, 4, 5];
for (const idx in arr) {
    arr.length = 0; // n.b. might be an indirect side effect of other code!
    const m = arr[idx];
}

Which would give you a wrong type at m

We don't intend to make noUncheckedIndexedAccess any smarter than it already is - nearly any attempt to make it smarter induces soundness holes in one case or another, and the point of the flag was to not have any indexing holes.

[ItsHarper]

Gotcha, that's fair. Thanks for responding!