Brendan Eich brendan at
Fri Dec 14 14:02:48 PST 2012

This boxed-primitive equation is a sore point, and perhaps some API 
should be standardized, but Number.isNaN is not that API. That's point 
#1, please ack it: we must have a predicate that applies only to true 
NaN primitives.

Point #2 is that we haven't heard the demand for such APIs until now. 
That means no ES6 late exception-granting, and for a Harmony strawman 
(ES7 or later) we would need to study the use-cases and exactly API 
details more closely. Mostly the use-cases, to see whether something 
important happens in the context of a given library or its "folkways" 
that won't -- or should not -- happen in the standardized core language.

Not all libraries have cowpaths that we want to pave. For one thing, 
libraries conflict. For another, some have design flaws.


John-David Dalton wrote:
> I apologize for the duplicate post, but I think my reply got lost in 
> its formatting.
> The Modernizr example was in response to Axel's request for an example 
> of boxed values being used in real world projects.
> Popular libs like jQuery, Dojo, MooTools, Prototype, and Underscore 
> have `isXyz` methods or equivalents that treat boxed and unboxed 
> values as like:
> For example:
> Underscore `_.isString('hi')` and `_.isString(Object('hi'))` both 
> return `true` also `_.isEqual('hi', Object('hi'))` returns `true`
> MooTools `typeOf('hi')` and `typeOf(Object('hi'))` both return 'string'
> Prototype `Object.isString('hi')` and `Object.isString(Object('hi'))` 
> both return `true`
> jQuery `$.type('hi')` and `$.type(Object('hi'))` both return 'string'
> Dojo `dojo.isString('hi')` and `dojo.isString(Object('hi'))` return `true`
> `Object(NaN)` is edge case, but lots of things in the spec are edge 
> (`-0` anyone).
> Because the majority of libs treat boxed and unboxed the same in their 
> `isXyz` I think it's natural for the spec to follow in the case of 
> `Number.isNaN`.
> Thanks,
> -JDD
> On Fri, Dec 14, 2012 at 12:01 PM, Brendan Eich <brendan at 
> <mailto:brendan at>> wrote:
>     Domenic Denicola wrote:
>             From: es-discuss-bounces at
>             <mailto:es-discuss-bounces at>
>             [es-discuss-bounces at
>             <mailto:es-discuss-bounces at>] on behalf of
>             Nathan Wall [nathan.wall at
>             <mailto: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 :( :( :(
>     Restricted productions creating new operators may be at risk
>     (Allen's right, we haven't had an orderly decision in TC39 on this
>     point), but or Object.isSameValue is definitely not dead.
>     Allen's right too that we have some disagreement on the use of
>     SameValue under the hood in Map and Set.
>     /be
>         (Someone want to find a link to the minutes that killed it? I
>         keep having to correct people on this.)
>             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 <mailto:es-discuss at>
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list