You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had an issue with Flow that it warned for no reason because I had an "if" to guard against undefined (facebook/flow#2984) - so I tried TypeScript. TypeScript didn't warn - but it also didn't warn when I removed the if-guards!
Here is the code I used to check with TypeScript 2.1.4. Strict null checks are "true", see tsconfig.json below. I only get a warning about the unused const test.
Just to cover those cases I added a test at the top of the function to be outside the inner promise callback function - same result.
Code
'use strict';constimap: {search(criteria: string[],cb: Function): void}={search: (criteria,cb)=>{}};constsearch=(from?: number,to?: number): Promise<number[]>=>{// 1) NOT SAFE, "from" could be undefined:consttest: boolean=from>=4;returnnewPromise((resolve,reject)=>{imap.search(['ALL'],(err: Error,uids: number[])=>{// 2) NONE of this is safe, "from" could be undefined:consttest: boolean=uids[0]>=from;uids=uids.filter((uid: number)=>uid>=from);uids=uids.filter(function(uid: number){returnuid>=from;});})});};
Error: from, used in a numeric comparison, could be undefined.
Actual behavior:
No warnings or errors other than the one about the unused variable test.
The reason Flow correctly complains (although it over-complains) is that comparisons of a number against something that is not a number is useless. If you end up with an undefined on one side and your type system didn't warn you of that potential problem it didn't do its job as far as I'm concerned (and boy am I glad to be able to point to the Flow guys to show that I'm not alone). An undefined is an error should it occur in that position. If the code simply runs through, because the Javascript sure won't tell you about it, you may be in some trouble. Likely much later in the code, hard to debug.
So no (or yes), simply avoiding the problem by including an additional check for undefined but not doing anything about it is probably useless because it's just another way to turn off the alarm bell.
In the case of the above code example there should probably be an Error thrown, because comparing against something that isn't there should not have a legitimate result.
So the purpose of the type system warning the developer here would not be so that the developer then goes ahead and promptly ignores the warning actively, but is forced to raise the alarm if it happens during runtime - which the type system cannot do for him/her.
The text was updated successfully, but these errors were encountered:
You get the expected errors with the current nightly drop. We tightened up checking of null and undefined in expression operators in #13483. It will be in the TypeScript 2.2 release.
TypeScript Version: 2.1.4
I had an issue with Flow that it warned for no reason because I had an "if" to guard against
undefined
(facebook/flow#2984) - so I tried TypeScript. TypeScript didn't warn - but it also didn't warn when I removed theif
-guards!Here is the code I used to check with TypeScript 2.1.4. Strict null checks are "true", see tsconfig.json below. I only get a warning about the unused
const test
.Just to cover those cases I added a test at the top of the function to be outside the inner promise callback function - same result.
Code
tsconfig.json:
Expected behavior:
Error:
from
, used in a numeric comparison, could be undefined.Actual behavior:
No warnings or errors other than the one about the unused variable
test
.The reason Flow correctly complains (although it over-complains) is that comparisons of a number against something that is not a number is useless. If you end up with an
undefined
on one side and your type system didn't warn you of that potential problem it didn't do its job as far as I'm concerned (and boy am I glad to be able to point to the Flow guys to show that I'm not alone). Anundefined
is an error should it occur in that position. If the code simply runs through, because the Javascript sure won't tell you about it, you may be in some trouble. Likely much later in the code, hard to debug.So no (or yes), simply avoiding the problem by including an additional check for
undefined
but not doing anything about it is probably useless because it's just another way to turn off the alarm bell.In the case of the above code example there should probably be an Error thrown, because comparing against something that isn't there should not have a legitimate result.
So the purpose of the type system warning the developer here would not be so that the developer then goes ahead and promptly ignores the warning actively, but is forced to raise the alarm if it happens during runtime - which the type system cannot do for him/her.
The text was updated successfully, but these errors were encountered: