NaN assertion is not strict enough

[olivr70]

NaN was recently hopefully recently added.

But because it relies on the global isNaN() function, it has the same flaws : because isNan() converts its argument before testing, it returns true in many unexpected cases, and false in others. It is not very predictible (i.e. isNan("bla") returns true, but isNaN("") returns false).

ES6 introduces Number.isNaN() which behaves as intuitively expected : if the value is a NaN, it returns true, otherwise (strings, dates...), it returns false. A very short polyfill for ES5 is proposed in the MDN documentation.

A strict isNaN is really needed. I can see 2 options :

1. rewriting the current NaN property using the MDN polyfill, but this would be a breaking change
2. implementing a strict NaN testing, which could be either
3. as a simple Property : .striclyNaN
4. using a flag like .stricly.NaN (expect(x).to.be.stricly.NaN;

I really think current isNaN() implementation is nearly useless, so I prefer the first option.

If the preferred way is option 2, then option 2.1 feels more like in the spirit of chai, which has different predicates for loose and strict versions of the same predicate (above/least, below/most, equal/eql).

I'm OK to do the job when this discussion will be closed.

[keithamus]

Lets make the breaking change - as you say, its useless if it throws up false positives.

There's a 4.x.x branch which you can make a PR into. When we release 4.0.0 we can release it with the breaking change 😄

[berkerpeksag]

This is fixed in cbfb6fd (in the 4.x.x branch, not master) and can be closed now.

[keithamus]

Thanks again @berkerpeksag 😄