Allen Wirfs-Brock allen at
Fri Dec 14 11:02:13 PST 2012

On Dec 14, 2012, at 10:45 AM, Domenic Denicola wrote:

>> From: es-discuss-bounces at [es-discuss-bounces at] on behalf of Nathan Wall [nathan.wall at]
>> Sent: Friday, December 14, 2012 13:34
>> On another note, I do sort of wonder why `Number.isNaN` is coming into the language now at the same time as the `is` operator and ``.  It seems teaching people (and getting them to remember long-term) the nuances of `isNaN` and `Number.isNaN` will be more difficult than just teaching people to use `x is NaN` in ES6 or `, NaN)` in an ES3/5 + ES6 shims environment.
> `is` operator is dead :( :( :(
> (Someone want to find a link to the minutes that killed it? I keep having to correct people on this.)

I may be wrong, but I don't think it was ever formally killed by TC39.   I was discussed here where the consensus was to kill it, but I don't recall an actual discussion at a TC39 meeting.  That's why I haven't deleted the is operator from the draft yet.   It's something I keep intending to verify at a meeting, but it keeps getting lost in the weeds.

BTW, I think there are probably other related issues that need to be discussed/resolved at that level.  For example, is SameValue really want we want for Map/Set equivalence (the -0 different from +0 issue), did we agree to parameterize the equivalance operator for Map/Set?,  and the question about the need for Number.isNaN if we have available.


>> There's not an `isNull` or `isUndefined`. The only reason `isNaN` was needed was because `===` didn't work with `NaN`, but `is` does.
> This is pretty reasonable, actually. The only argument I can see is that `array.filter(Number.isNaN)` is shorter than `array.filter(x =>, NaN))`.
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list