TypeScript Version: 2.2.2

Code

// A *self-contained* demonstration of the problem follows...
let a : 0 | 1 / compiles
let b : 0 | NaN // fails : Cannot find name 'NaN'
let b : 0 | Inifinity // fails : Cannot find name 'Inifinity'
let b : 0 | -Inifinity // fails : Cannot find name '-Inifinity'

Expected behavior:
Well, NaN, +Infinity and -Infinity are valid numbers, so I see no reason they should not be accepted

Actual behavior:
It fails to compile

** Benefits **
I discovered this was all discussed in #9407. @ahejlsberg and @weswigham explicetly took position against including it, except for a compelling case...

Other than being the intuitive result (why on earth a perfectly valid number would not be acceptable a in a number literal type, I see several benefits :

One application would be the Math.sign() type definition. It is currently defined as returning a number although the spec says it can only return 0 | -0 | +1 | 1 | NaN
This is in fact how I got into the problem : I wanted to implement a comparator function (returning -1|0|1) using Math.sign( ), intuitively expecting to be limited to those 3 values (and at the time forgetting about NaN)

To continue with the Math.sign, it could be defined as follows

interface Math {
  sign(x:NaN):NaN
  sign(x:number):0|1|-1
}

This way, it explicitely states when the function returns NaN and be extremely useful for documentation purposes (I suppose modifying a compiler for documentation is not very strong...)

Another one I can see (although it's a quick thought) : I think it could provide very interesting handling of NaN (if we had substraction types #4183)