Repository navigation
noUncheckedIndexedAccess does not narrow properly when iterating with for...in #58082
Closed as not planned
Description
🔍 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
📃 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.
Activity
ItsHarper commentedon Apr 4, 2024
A similar case to this was reported as #43614, and resolved in #51653.
[-]Allow iterating through a Record with `noUncheckedIndexedAccess` enabled without having to handle `undefined`[/-][+]`noUncheckedIndexedAccess` does not narrow properly when iterating with `for...in`[/+]jcalz commentedon Apr 4, 2024
Could you edit to talk about index signatures instead of
Records? ARecord<K, V>isn't required to have an index signature (e.g.,Record<"a", string>).RyanCavanaugh commentedon Apr 4, 2024
You could still write
Which would give you a wrong type at
mWe don't intend to make
noUncheckedIndexedAccessany 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 commentedon Apr 4, 2024
Gotcha, that's fair. Thanks for responding!