Allow logical XOR using `^` operator

[drewnoakes]

Consider:

var a: boolean = ...;
var b: boolean = ...;

if (a ^ b) {
  // ...
}

Currently attempting to use the ^ operator on boolean values fails with:

error TS2113: The left-hand side of an arithmetic operation must be of type 'any', 'number' or an enum type.

The | and & bitwise operators have logical counterparts, || and &&. No such ^^ is available.

JavaScript allows bitwise XOR to apply to boolean values.

Currently workarounds are:

• casting: <number><any>a ^ <number><any>b
• using a negated equality test: a !== b

The XOR operator is clearer than both of these.

[RyanCavanaugh]

Seems reasonable, though there may have been some reason for this I'm not aware of.

[drewnoakes]

Care will be required in resolving the type of the result. I suspect it should invalid to apply the operator to a number and a boolean.

[RyanCavanaugh]

Notes for design meeting

• Runtime behavior
  • Operands of ^ are converted to number
  • The result is always number
  • e.g. true ^ false is 1, false ^ false is 0, true ^ 1 is 3 (truthy)
  • Shortest actual workaround for boolean-typed x ^ y is +x ^ +y
• Recommendations
  • The result of the operation is of type number
  • number ^ boolean or boolean ^ number is disallowed

[RyanCavanaugh]

Discussed in design meeting and declined. Relevant points:

• !== is equivalent and not necessarily less clear (plus it returns a value of the appropriate type)
• If we supported ^ for boolean, we'd want to support & and | for consistency, but catching && vs & errors is important

[sophiajt]

We went back and forth on this one. One of the confusing aspects of supporting a boolean ^ boolean is that we'd rather not support the same for & and |. The reasoning here is that this is a fairly common error to accidentally type & when you meant && (and likewise for | vs ||). We'd like to continue to help catch errors like this. This leaves ^ as an exception to the rule rather than a rule the other operators follow.

For simplicity, I think the preference is just to instead prefer the pattern of using a !== b rather than a ^ b and introducing more type overloads for ^.

[sophiajt]

Look at that, Ryan's message popped up. What he said :)