31–40 of 167 posts
I think they're just waiting on support for the new syntax in prettier.
For this code: const x = [1,2]; const y = x[666]; const z = y + 3; Is there a way for TypeScript to flag the last line as a type error? TypeScript will say "y" has type "number" when "x[666]" returns undefined. Why does TypeScript not say the type of "y" is "number | undefined"?
Not really https://github.com/microsoft/TypeScript/issues/9235 Though with tuples, etc. being defined, maybe it's worth re-examining.
I haven't tried it yet but it looks like the new optional element access feature is only checking if the array itself is defined, not if the array index is defined.
I really like the new optional operator, this might be what gets me to bite the bullet and start moving some of my projects over to typescript - dealing with potential undefined objects in those chains is one of the things I actively dislike about writing in vanilla Javascript.
For this code: const x = [1,2]; const y = x[666]; const z = y + 3; Is there a way for TypeScript to flag the last line as a type error? TypeScript will say "y" has type "number" when "x[666]" returns undefined. Why does TypeScript not say the type of "y" is "number | undefined"?
https://www.typescriptlang.org/play/index.html#code/MYewdgzg... Using `as const` will report both the 2nd and 3rd lines as type errors. You've been able to do this in TypeScript for a while even before they introduced the `as const` syntax.
const x = [1, 2] as const;
const r = 666 + 1;
const y = x[r];
const z = y + 3;For this code: const x = [1,2]; const y = x[666]; const z = y + 3; Is there a way for TypeScript to flag the last line as a type error? TypeScript will say "y" has type "number" when "x[666]" returns undefined. Why does TypeScript not say the type of "y" is "number | undefined"?
const x = [1,2] as const;
//const x: [number, number] = [1,2];
const y = x[666];//Tuple type 'readonly [1, 2]' of length '2' has no element at index '666'.
const z = y + 3;//Object is possibly 'undefined'.
... but with that being said, 3.7 seems to have broken many aspects of the `Promise.all` interface. Right now the largest issue seems to be that if any `Promise` result in `Promise.all` is nullable, all of the results are nullable.
log?.(`Request started at ${new Date().toISOString()}`);
// roughly equivalent to
// if (log != null) {
// log(`Request started at ${new Date().toISOString()}`);
// }