[NaN].indexOf(NaN) === -1 VS Object.is(NaN, NaN)

[Andrea Giammarchi]

This is basically what I am doing except I find Array#indexOf as it is
pointless ... or better, something that should be fixed in the next version
of ECMAScript.

Right now I am feature detecting the inconsistent behavior ... but a
feature detection that will never possibly return true is also pointless
... thanks in any case :-)

br


On Thu, Jun 14, 2012 at 12:41 PM, Mark S. Miller <erights at google.com> wrote:

> Please replace your use of indexOf in your collection implementations
> instead. If indexOf is more efficient than one written in JS using
> Object.is, then use the fast one when the argument is anything other
> than NaN, 0, and -0.
>
> On Thu, Jun 14, 2012 at 3:24 PM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> wrote:
> > Hello everybody,
> >     I am not sure about the status of this subject but I find quite
> > inconsistent the fact we cannot trust Array#indexOf when it comes to NaN
> ...
> > I am updating my es6-collections shim accordingly with what Paul Millr
> said:
> > my shim does not consider NaN as a valid key, being unable to find a
> match
> > through indexOf, so each NaN key will result into a new one for both Map
> and
> > Set ( broken WeakMap too )
> >
> > I wonder if in the next future Array#indexOf will use internally
> Object.is
> > to compare values or if I have to use my own function to loop over all
> > values and do this kind of comparison.
> >
> > Any thought on this will be appreciated and apologies if this has been
> > discussed already ( so a quick answer on "how it's going to be" would be
> > more than enough )
> >
> > Best Regards,
> >     Andrea Giammarchi
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
> --
>     Cheers,
>     --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120614/25cd01e5/attachment.html>