Add the strictMathChecks option to allow for less complex code with math operations

Suggestion

🔍 Search Terms

“undefined math”

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn’t be a breaking change in existing TypeScript/JavaScript code
• This wouldn’t change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn’t a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript’s Design Goals.

⭐ Suggestion

Typescript currently produces an error when comparing undefined or null in math operations. While this may be wanted in some situations, not everyone may want this and it has been a big source of errors in my code. I would like to suggest the addition of a tsconfig option called “strictMathChecks” that would default to true (current behavior) and, when false, would allow for comparison with undefined or nan in math operations. The reasons why I believe this would make sense are the following:

• The current alternative to this is doing Number(variable) on the variable that is producing the error, which turns it into NaN and can then be compared (always returning false) and produces the same result
• In JavaScript, you can compare null/undefined in math operations and no error will be thrown, which does the same as using NaN like shown above.

Here are some short examples:

undefined > 50 // returns false in JS but throws an error in TS
NaN < 50 // returns false and does not throw an error in TS
null <= 100 // returns false but throws an error in TS

📃 Motivating Example

TypeScript will now allow you to use undefined/null values in math operations when the strictMathChecks option is set to false. This allows for less redundant code.

💻 Use Cases

As I explained above, the workaround for this error is pointless since this syntax is valid in JS, and applying it does not change the behavior at all, so it just becomes a minor inconvenience.

[jcalz]

You’ll probably need a more convincing criterion than “this is valid JavaScript so it should be valid TypeScript”. Generally the threshold for TypeScript warnings is not set at “will this code lead to a runtime error?”; that would be fairly useless because JavaScript lets you write all sorts of crazy things without producing a runtime error. Rather, the bar is set at “is this code likely to be a mistake?”. See What does “all legal JavaScript is legal TypeScript” mean? for more info.

So that means it should depend on how much real-world idiomatic JavaScript is out there where someone writes foo > 50 and it’s okay if foo turns out to be undefined or null. If you think there’s a bunch of that, you should show some of it in your motivating example code (as opposed to undefined > 50 which is nothing anyone would ever write… and not very relevant to whether this should be allowed or a bug, since nobody would write 30 > 50 either). Right now you seem to be suggesting that the current situation is a minor inconvenience, and you’d like to alleviate that inconvenience to support… what, exactly? What math operations are commonly used where foo > 50 does good things if foo turns out not to be a number?

[fatcerberus]

“undefined as a stand-in for zero” doesn’t feel like a strong argument since undefined < 1 is also false.