Suggestion: stricter operators

[evmar]

Currently operators like "+" are defined such that they match their semantics in JS. The below are all allowed by the compiler and produce the shown values, even with --strictNullChecks on.

• 2 + 'a' => "2a"
• null + 'a' => "nulla" (!)
• 2 - null => 2

I propose letting users opt in (maybe via some --strictOperators) to strict operator behavior. Concretely I think this means:

• restrict +, and += to just number and string, e.g. for the former only declare

  function +(a: number, b: number): number;
  function +(a: string, b: string): string;

• restrict - and -= to just number

(any should continue to work as normal, of course.)

Relevant spec section:
https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md#419-binary-operators

See also "Expression operators" in the strictNullTypes change: #7140
and in particular this rationale: #7140 (comment)

This would fall under of "stricter" TypeScript, #274 .

[basarat]

number + string is actually quite common in JavaScript land and will probably not happen as it moves the convenience - type safety slider too much towards safety.

null + string should be disabled as a part of strictNullChecks.

Note:

A number of wat things are disabled in TypeScript e.g. [] + [] (valid JavaScript, produces "") is an error in TypeScript. Similarly "hello" + 1 is allowed (like I mentioned) but "hello" - 1 is an error 🌹

[zpdDG4gta8XKpMCd]

related #7746

[myitcv]

@basarat I really struggle when the argument "because that's how Javascript does it" is applied. Particularly in cases like this where I think the cognitive load on the developer is increased by decisions to stick to the Javascript way. Not because it's unclear how + behaves, rather that is creates cognitive dissonance with the rest of the type system:

let s: string;
let n: number;

s = n;            // ERROR: number is not assignable to string
n = s;            // ERROR: string is not assignable to number

let res = s + n;  // OK: really?

I understand that + is defined by the spec to work on combinations of number and string and so has well-defined behaviour, but given the example above I think it's more confusing than useful for it to have been defined in this way (the Javascript way). Particularly when explicit conversion is so simple and more readable.

[mhegazy]

@myitcv how is different from #7746?

[myitcv]

@mhegazy because as I understand it, there is no coercion when it comes to +; it's simply specified to operate on various combinations of types.

[mhegazy]

@Aleksey-Bykov do you agree that this suggestion encompasses the one in #7746?

[zpdDG4gta8XKpMCd]

i agree, thank you for considering

[RyanCavanaugh]

Approved behavior change: under --strictNullChecks it should be an error to use a possibly-null/possibly-undefined operand in a +, -, /, *, |, &, ^, or ** expression. One exception is that string + nullable is still OK since that's very common for producing debugging strings.