for...of with strictNullChecks

[johnfn]

I was able to dig up a lot of discussion about why myArray[i] should not be a nullable type, and that makes sense. But I wasn't able to dig up anything on for ... of loops.

How come the following:

const x = ["a", "b"]
for (const y of x) { /* ... */ } 

makes y a nullable type? All the arguments saying myArray[i] shouldn't be a nullable type also seem to apply to for ... of loops, as far as I can see.

[jods4]

+1
I have the same issue here. for..of is conceptually the same as indexer access or .forEach() or .map() or anything that works with an array. The same arguments apply: if I don't declare my array as containing undefined values, it's unusable to implicitely add them.

Example from our codebase:

function frob(changes: ChangeRecord[]) {
  for (const change of changes) {
    // TS 2.0 infers change: ChangeRecord | undefined
    // All uses of `change` are correct but create a "Object is possibly 'undefined' error
  }
}

[jods4]

Just noticed that the problem also exists for the spread operator:

const source: number[] = [1,2,3];
const target: number[]  = [];
target.push(...source);  // error TS2345: Argument of type 'number | undefined' is not assignable to parameter of type 'number'

[mhegazy]

If you are using the version of the library that ships with the compiler, you shouldn't see this behavior see #8357.

The behavior you are seeing is caused by a stale declaration of IteratorResult. My guess is you have a custom version of lib.es6.d.ts locally, and that is what is being used. if this is correct, please update your declaration file to have IteratorResult.value be non-optional. see #8450 for more details.

[johnfn]

Yup, that was the issue. Thanks, @mhegazy.

[jods4]

Ha... I switched to the new TS modular libs after making sure the code compiled.

I see now that the issue went away, indeed.

[mhegazy]

thanks for verifying. closing.