NaN, Infinity and -Infinity not accepted in number literal types

[olivr70]

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)

[RyanCavanaugh]

it explicitely states when the function returns NaN and be extremely useful for documentation purpose

Basically comes down to this. The first signature there would only ever be hit when writing exactly Math.sign(NaN), which... why would you ever do that (or anything equivalent where you already know that a value is NaN).

A secondary objection is that NaN is not semantically a unit type the same way 0 is -- any number of different invalid operations produce NaN; this is also somewhat true of Infinity. NaN's odd behavior with === would also introduce a bunch of extra logic in how we narrow.