5 ms·
Sort of. Strict null checking now lets you distinguish between the types Foo[] and (Foo | undefined)[]. The first will type with the assumption that there are
by curveship 9y ago
Sort of. Strict null checking now lets you distinguish between the types Foo[] and (Foo | undefined)[]. The first will type with the assumption that there are no out of bounds indices (which, as you say, could be wrong). The second will require you to always check the result of array dereferences to see if they're undefined before you reference the object.
var foos1 = [] as Foo[],
foos2 = [] as (Foo | undefined)[];
// ... later
var foo1 = foos1[i],
foo2 = foos2[i];
foo1.bar(); // types fine, TS assumes non-undefined
foo2.bar(); // TS type error, as you haven't checked undef
if (foo2) foo2.bar(); // types fine, undef excluded
- vosper 9y ago> (Foo | undefined)[] This says "either an array of Foo or an array of undefined", right? Not "either an array of Foo or just undefined"?
- jiaweihli 9y agoNo, (Foo | undefined)[] means an array of elements that are either of type Foo or are undefined. Foo[] | undefined[] means either 1) an array of Foo, or 2) an array of undefined.
- vosper 9y agoAhh got it - thanks!
- josteink 9y agoIt says an array whose elements can be either Foo or undefined.
- yoklov 9y agoThis isn't the issue I'm describing at all. E.g. if I missed a bounds check, and access past the end of a `Foo[]`, it would be typed as `Foo` (and not `Foo | undefined`), but really be `undefined. Consider this code. var foos: Foo[] = [new Foo()]; foos[1].bar(); foos[1] will be undefined (since it's past the end of the array) but will typecheck as a Foo. Obviously it's bad if I forget a bounds check, but it's similarly bad if I forgot a null check. Of course, I understand why this issue exists, but it is an issue.