Reassigning of inferred `object` with Indexed access value does not widen it's type

[svenvandescheur]

🔎 Search Terms

Type Inference
Indexed Access Types
object type
keyof object
type assertion
control flow narrowing
type widening
no implicit any

🕗 Version & Regression Information

?

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/FAMwrgdgxgLglgewgAgCYFN0AcDi6YAUAFgIYCeAzjCVANYBcyCARgFbqwA0yWJMRjKgCc4EAOYBKZAG9gyZFCRVkFDvCXIAvDz5EAdBSwAbOIQBEesxIDcc5EfwKwQoeggwAymsQRBMEeLW8gD0wcge-qJi3BAIMMgQHFDoFBQkIkZkyCTItOhkCCBMbGp6dg7xAG4kRmDoWsiklNR0QcihyACSECDoLuioxeywwHYA7kRwDsgEqrA+FHoO4vxSsvLyUM6u7l7zSA1z6hCLFJMghFIAPlfIZmZtHREB0QlxCUkpaRlZOXkFRRYwxgZQ2CiU8X+DS2-V23gOJAouXyhWQMDIWHQqOqtXq7TCABUMRxEfEAAb-MlohDIZj1P75ZBkoFqMncUwAciROLqyFcAFsSKIkbFIbExhBQRsefVtDKANr-AC6jzCMpURAQYCMqEARIS0+kQLIEBBCZCQWjiiDcU0fSp9AD8UmYWXF2SR-D69TgIppY3I1LR6CMRjRRHqin6sDRxIddgAvnZXDBnCgZaqmTK2chWGBlIimCgTIlkABGAAMyB9VZ6fVcgwLzJKsGz6HtKH4WrERFproQYyrMC5MywCFScGYmSkFAQ-Pwk3EyGDqjKieAHQJkyR1c9NawYHiLOjeYGyBAtpgKXg4jKihOh7YDXWG3PCEYz7B8mY6UYZm-QjMOx5ETNc72UVA+BybQMGwPBCCBbgzFfPR-ysEIwjJCDqCpasxlMTUD3BfljCFdwY0xBskSbYEyWAMCEAcJYEDEAh0UxVEsJIbhOKkfFGn7Ns+kLPlIHgOd2XiFMhBOJhCM5KjhCiMk9CAA

💻 Code

function deepGet(haystack: object, path: string) {
  const sections = path.split(".");
  let currentSection: string;  // String, not neccessarily a keyof object.
  let value = haystack;  // Inferred object

  while (sections.length) {
    currentSection = sections.shift() || "";  // String, not neccessarily a keyof object.
    const key = currentSection as keyof typeof value  // Typecast `key` to be a key `object`, it's value remains any/unknown.
    value = value[key];  // value should™ be any/unknown by now as there is no way to tell the correct type?
  }
  return value;  // `value`, just as on line 10 is inferred as `object`, even though by now it's (possibly) something else.
}

// This is the input object used for testing.
const obj = {
    foo: {
        bar: "bar"
    }
}

const data = deepGet(obj, "foo.bar")  // `data` is without complaint typed as `object`
console.log(typeof data, data)  // however on runtime, it turns out it's `string`.

🙁 Actual behavior

let value: object

🙂 Expected behavior

Element implicitly has an 'any' type because expression of type 'string' can't be used to index type

Additional information about the issue

No response

[nmain]

Could you make sure your repro is correct?

Your comment says "any/unknown" (although those are two different types 😕):

const key = currentSection as keyof typeof value  // Typecast `key` to be a key `object`, it's value remains any/unknown.

But in the playground, key has a type of never here:

That makes me suspect that you did this example with a different combinations of compiler flags than you actually set in the playground.

[svenvandescheur]

@nmain I've clarified the ts playground example with better comments. With any/unknown I ment that that the value is not known, not that is should strictly be any (mixed with unknown). This was a confusing mixup of natural language and TS here, sorry for confusion 😅

I'm not exactly certain what the type of the updated value should be, but I would expect an implicit any warning. I do think it should definitely not be object since there is no way to guarantee this.

The ts playground should be set with the default flags (I did not touch that).

[MartinJohns]

I would say this is working as intended / by design.

The key is typed never, so the indexed access value[key] becomes any. Assigning an any value to a variable does not change the type of the variable to any (which I believe is intentional as well).

[svenvandescheur]

The key is typed never, so the indexed access value[key] becomes any

Should this become any, I would assume that the result would also become never as this lookup should not occur?

Assigning an any value to a variable does not change the type of the variable to any (which I believe is intentional as well).

I'm kinda surprised by this. This could easily lead to incorrect types as any is wider than other types?

[MartinJohns]

Should this become any, I would assume that the result would also become never as this lookup should not occur?

🤷‍♂️ never is a valid keyof Whatever, so it's legal. See also #53345.

I'm kinda surprised by this. This could easily lead to incorrect types as any is wider than other types?

It's the very point of any and what it's there for: to opt out of type checks. One could argue whether the index access should yield unknown instead of any tho. I believe this behavior predates the introduction of unknown. Related issue: #27265 (tho I'm not sure if this qualifies as an implicit any).

Given the dynamic nature of these checks it would make sense to use any, because otherwise you couldn't really meaningful use the value without an additional type cast.

Perhaps there's an eslint rule to forbid this kind of usage, but I couldn't find one right away.

[nmain]

The dragons were let out when you did the as cast here. Those always have the potential to be unsafe.

const key = currentSection as keyof typeof value

This is a strange line, as typeof value is just object, so why not use that, and keyof object is never as that type has no known keys in the type system.

Perhaps there's an eslint rule to forbid this kind of usage, but I couldn't find one right away.

Could use this one:

Unsafe type assertion: type 'never' is more narrow than the original type @typescript-eslint/no-unsafe-type-assertion.

[MartinJohns]

Perhaps there's an eslint rule to forbid this kind of usage, but I couldn't find one right away.

Could use this one:

Unsafe type assertion: type 'never' is more narrow than the original type @typescript-eslint/no-unsafe-type-assertion.

I guess. I was thinking more towards not indexing with any or never types.

[nmain]

https://typescript-eslint.io/rules/no-unsafe-member-access/ handles an any indexer but not a never indexer.

[svenvandescheur]

Should this become any, I would assume that the result would also become never as this lookup should not occur?

🤷‍♂️ never is a valid keyof Whatever, so it's legal. See also #53345.

I'm kinda surprised by this. This could easily lead to incorrect types as any is wider than other types?

It's the very point of any and what it's there for: to opt out of type checks. One could argue whether the index access should yield unknown instead of any tho. I believe this behavior predates the introduction of unknown. Related issue: #27265 (tho I'm not sure if this qualifies as an implicit any).

Given the dynamic nature of these checks it would make sense to use any, because otherwise you couldn't really meaningful use the value without an additional type cast.

Perhaps there's an eslint rule to forbid this kind of usage, but I couldn't find one right away.

Thx for the info, I think his clears out a lot why it happens and as I read the comments it reads as working as intended? Nevertheless I feel there is a lot of counter intuitive behavior here:

• Defaulting to any feels wrong, specially given how wide any is and what potential side effects this may have. Defaulting to unknown feels like more a correct behavior to me.

• The linked issues states that never is intentionally a valid keyof object, can't really get my head around this one as I feel that never should be a noop. A result of never when indexing never feels like a more correct behavior to me.

[nmain]

The type never has no values in it, so it logically satisfies every possible predicate.

If you're asserting that a particular value as type never, you're essentially asserting that execution can never reach that point, otherwise it would have a non-never value.