Object is possibly undefined` error in TypeScript 4.1.2

[doberkofler]

TypeScript Version: 4.1.2

Search Terms: Object is possibly undefined

Code

function main(values: Array<string>) {
    for (let i = 0; i < values.length; i++) {
        if (typeof values[i] === 'string' && values[i].length > 0) {
            console.log(i);
        }
    }
}

Expected behavior:
No error

Actual behavior:
TypeScript 4.1.2 reports a Object is possibly undefined error in values[i].length but given the first condition the object must be defined as it is of type 'string'

Playground Link: https://www.typescriptlang.org/play?noUncheckedIndexedAccess=true&ts=4.1.0-beta#code/GYVwdgxgLglg9mABAWwIYzACgG6oDYgCmAzgFyICCATlagJ4A8xUVGA5gHwCUiA3gFCIhiYHCqJMeQlEQxEAXkQAGANyzEDRLgIkAdFLBsoACzUwA1OZ4Dht2cAlQ6AB0JwH2osQDaMALoK8ooA5MyshsGIAGRRWvhevn76hIYmiBzK1oJ2ORAIxHBS+nBsmDBcKtk5AL5ViLW1QA

Related Issues: no

[MartinJohns]

Duplicate of #10530. Type narrowing does not occur for indexed access forms e[k] where k is not a literal.

[doberkofler]

@MartinJohns Sorry for the duplicate, but I would not have found it and really looked. I just wanted to add that this specific use case of the problem is the main cause for an immense number of "false errors" when activating the new noUncheckedIndexedAccess flag in my code base.

[RyanCavanaugh]

This was one of the caveats that kept the flag from being implemented for so long. We don't have any way to ascertain whether i or the indexed array has changed between any two arbitrary expressions, so the only "safe" thing to do is always include undefined. You can write

function main(values: Array<string>) {
    for (let i = 0; i < values.length; i++) {
        const el = values[i];
        if (typeof el === 'string' && el.length > 0) {
            console.log(i);
        }
    }
}

[thecotne]

@RyanCavanaugh this should work as well

function main(values: ReadonlyArray<string>) {
    for (let i = 0; i < values.length; i++) {
        if (typeof values[i] === 'string' && values[i].length > 0) {
            console.log(i);
        }
    }
}

since ReadonlyArray can't magically change what indexes are in the set and what are not

[doberkofler]

@thecotne Just to make sure: it should but it does not. Correct?

[thecotne]

@doberkofler sorry for confusion. it should but it does not.

https://www.typescriptlang.org/play?noUncheckedIndexedAccess=true&ts=4.1.0-beta&ssl=1&ssc=31&pln=1&pc=23#code/GYVwdgxgLglg9mABAWwIYzACgG6oDYgCmAzgFyIBKhqAJgngJ4CCATi6gwDzFQsYDmAPgCUiAN4AoRNMTA4LRJjyEoiGIgC8iAAwBuNYk6JcBEgDplYflAAW+mAGoHoyTLdrgiqAwAOhOJ4mRMQA2jAAupoaWgDkPHxWMYgAZMnG+MFh4RaEVraIgjouUu6lEAjEcMoWcPyYMMK6JaUAvs2IbS1AA

[Skillz4Killz]

Have you considered using a for of or forEach loop?

function main(values: Array<string>) {
    for (const value of values){
        if (value) {
            console.log(value);
        }
    }
}

function main(values: Array<string>) {
    values.forEach(value => {
         if (value) {
             console.log(value);
         }
    })
}

[doberkofler]

@Skillz4Killz You are absolutely correct. The code snipped is just an example for the generic problem where the array element is first tested and then used if available.

[saperdadsk]

@doberkofler Consider the following (contrived) example though

function main(values: Array<string>) {
    for (let i = 0; i < values.length; i++) {
        const incrementI = () => {i = i + 1;}
        if (typeof values[i] === 'string' && incrementI() && values[i].length > 0) {
            console.log(i);
        }
    }
}

values[i].length is no longer guaranteed to be defined, and TS has no good way to detecting that change.

[RyanCavanaugh]

since ReadonlyArray can't magically change what indexes are in the set and what are not

This isn't true. A ReadonlyArray might be an alias for an underlying mutable array. e.g.

function fn(cb: (arr: ReadonlyArray<number>, clear: () => boolean) => void) {
  let arr = [1, 2, 3];

  cb(arr, () => {
      while(arr.length) arr.pop();
      return true;
  }) 
};

// Crashes
fn((arr, clear) => {
    let i = 0;
    if (arr[i] !== undefined && clear() && arr[i].toFixed() === "1") {

    }
})

[peterholak]

This was one of the caveats that kept the flag from being implemented for so long. We don't have any way to ascertain whether i or the indexed array has changed between any two arbitrary expressions, so the only "safe" thing to do is always include undefined.

But doesn't narrowing on all object properties work in the "unsafe way" in TypeScript anyway? E.g.

type X = { word: string|undefined }

function bad(obj: X) {
    if (obj.word !== undefined) {
        mutate(obj)
        return obj.word.length
    }
    return undefined
}

function mutate(obj: X) {
    obj.word = undefined
}

console.log(bad({ word: 'hello' }))

Produces a run-time error, but no TypeScript errors. Of course noone should ever write code like this, but it's the same principle.

It's a shame that JS doesn't have better native support for immutable data. The "edge case" of mutability is preventing such a useful feature from working conveniently in the huge percentage of codebases that never mutate most stuff anyway (especially non-local stuff).

[RyanCavanaugh]

The entire point of the flag was to be more safe than TS's normal behavior, so it being more restrictive than the default is a not undesirable aspect.

[yume-chan]

I know TS doesn't recognize this pattern, even for normal optional properties:

interface Foo {
  bar: string | undefined;
}

declare const foo: Foo;

if (foo.bar) {
  foo.bar.toLowerCase(); // OK
}

const bar = 'bar';
if (foo[bar]) {
  foo[bar].toLowerCase(); // Object is possibly 'undefined'.
}

(Playground link)

However I can't understand why:

If it's because a variable (bar in this case) may change between two accesses, since bar is a constant, it's not possible.

If you say the object (foo in this case) may change, then why does accessing with literals work? I expect they (access with literals and variables) both work or not work, and I prefer both not.