Closed
Description
Bug Report
type guard in undefined array indexed access
🔎 Search Terms
🕗 Version & Regression Information
- This changed from version 4 with the introduction of noUncheckedIndexedAccess
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
- I was unable to test this on prior versions because _______
⏯ Playground Link
💻 Code
const abc: Record<string,string> = {};
function bar( arg: string ) {
if ( arg in abc ) {
const data = abc[ arg ];
}
}
🙁 Actual behavior
data is string|undefined
despite it being typeguarded with "in" on a Record<string, string>
which means that it cannot be undefined
🙂 Expected behavior
data
should be string
The current bug causes either lots of redundant code (as we have to typeguard for undefined again separately) or disabling noUncheckedIndexAccess
which would snooze tons of potential bugs though.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
jcalz commentedon May 13, 2023
Being tracked at #10530. The issue is that
arg
is of typestring
and not a string literal type. Observe the difference:Until and unless #10530 is fully resolved, the most ergonomic way to do what you're doing is to give up on
in
and just check forundefined
:Playground link to code
kkmuffme commentedon May 13, 2023
That issue is vaguely similar at best - the referenced issue refers to all (other) keys to be inferred as non-undefined and only for LITERAL strings.
However here it's about a non-literal string which has explicitly been checked with
in
and not about inferring any other keys/types that might exist on the object too.
jcalz commentedon May 13, 2023
Sigh, no it's the right issue, it's just that the description isn't quite specific enough anymore. I'd edit the title if I could. See #53454 for example.
RyanCavanaugh commentedon May 16, 2023
This was the entire concern of the feature in the first place when we implemented it. People wanted a sound and convenient method to check for array bounds or key inclusion automatically. And we said, "We don't have any way to do that since both index and map/array mutation can happen at almost any time," and everyone said, "No, that's fine. We can deal with the inconvenient but sound version, having anything is better than nothing for sure." So that's what we have, and indeed it is inconvenient in some cases.
microsoft-github-policy-service commentedon May 19, 2023
This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.
microsoft-github-policy-service commentedon May 19, 2023
This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.
fatcerberus commentedon May 20, 2023
@RyanCavanaugh I suppose there's an argument to be made that naming a feature "no unchecked indexed access" was misleading when it errors even in cases where the index is checked (via
in
, e.g.), and the enforced contract is actually that you check the value you receive, not the indexed access itself (which can remain unguarded).But yeah, this is a good case-in-point for why noUncheckedIndexedAccess isn't the default.