Disallow truthiness coercions on known-true/known-false values

[RyanCavanaugh]

Inspired by #7746 but making a new issue for clarity

Bad code:

function func(): boolean { return Math.random() > 0.5; }
if (func) {
  // oops, meant to write func()
}

Change: Under --strictNullChecks, it becomes an error to use an expression in a truthiness position unless the type of the expression is possibly-falsy

Possibly-falsy types are:

• any
• The primitives: string, string literal types, number, enum types, and boolean
• Type parameters
• Union types containing possibly-falsy types
• An intersection type where any member is possibly falsy

A truthiness position is:

• The test expression of an if, while, or do/while
• The middle expression of a for
• The first operand of ?, && or ||
• The operand of !

[RyanCavanaugh]

cc Anders Hejlsberg (@ahejlsberg)

[RyanCavanaugh]

I tried implementing this since it's pretty easy now under --strictNullChecks. It did not go well.

A nonexhaustive list of problems:

• Interfacing with .d.ts files from non-strictnullcheck libraries is a disaster, since we assume all values from those libraries are truthy. This is perhaps a dealbreaker because this is going to be very common for a long time.
• Need to special-case while (true) {
• Since we don't include | undefined in the type of index access expressions, good checks like if (map[key]) { become errors. Not at all clear how we'd fix this except by perhaps trafficking around a "possibly-falsy but assumed-truthy" flag on those expressions, which would be a mess.
• while(foo) { while(foo) { becomes an error because foo is assumed truthy inside the loop, but it may be mutated

[RyanCavanaugh]

Idea from SBS is to check the specific syntactic forms

if (x) {

and

if (x.y) {

to see if x is non-nullable with call signatures. This should catch a few bugs while not having too many false positives.