> <span class="" style="font-family:arial,sans-serif;font-size:13px">No. Object.is correctly reports that these are different.</span><div><span class="" style="font-family:arial,sans-serif;font-size:13px"><br></span></div>
<div><span class="" style="font-family:arial,sans-serif;font-size:13px">Ah yap, I've had my head in lib code for a while. I'm used to the behavior of `_.isEqual(3, Object(3)); // => true`</span></div><div><span class="" style="font-family:arial,sans-serif;font-size:13px">but you're right the current behavior of `Object.is(3, Object(3)); // false` so yap it makes sense that it's that way for `NaN` and `Object(NaN)` as well.</span></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 13, 2012 at 8:36 PM, Mark S. Miller <span dir="ltr"><<a href="mailto:erights@google.com" target="_blank">erights@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Dec 13, 2012 at 8:25 PM, John-David Dalton<br>
<<a href="mailto:john.david.dalton@gmail.com">john.david.dalton@gmail.com</a>> wrote:<br>
> Yap yap, so thoughts on `BuiltinNumberWrapper` instead of `Type(…)`? It<br>
> would still prevent the global `isNaN('foo')` confusion. Though<br>
> `Object.is(NaN, Object(NaN))` currently returns `false` too. Was this just<br>
> an oversight?<br>
<br>
</div>No. Object.is correctly reports that these are different.<br>
<div class="im HOEnZb"><br>
<br>
> I know `Object(NaN)` is totally edge case but it still has the<br>
> brand of BultinNumberWrapper and is NaN (boxed).<br>
><br>
><br>
><br>
> On Thu, Dec 13, 2012 at 8:18 PM, Luke Hoban <<a href="mailto:lukeh@microsoft.com">lukeh@microsoft.com</a>> wrote:<br>
>><br>
>> >> From: Mark S. Miller [mailto:<a href="mailto:erights@google.com">erights@google.com</a>]<br>
>> >><br>
>> >> In that case, the current spec is wrong. The purpose of introducing<br>
>> >> Number.isNaN is to repair the >> following bug in the global isNaN:<br>
>> >><br>
>> >>     isNaN("foo") // returns true<br>
>><br>
>> Indeed, as Yusuke noted on the other reply, I referred to the wrong<br>
>> 'isNaN'.  And as you note, the point of the 'Number.isNaN' variant is to<br>
>> avoid any coercions.<br>
>><br>
>> That still leave's JDD's original suggestion to allow<br>
>> Number.isNaN(Object(NaN)) to return 'true' by checking for either primitive<br>
>> or boxed Number.  It feels a little odd to introduce another kind of limited<br>
>> coercion into the language, but perhaps it is practically valuable to not<br>
>> differentiate boxed and unboxed numbers here?<br>
>><br>
>> Luke<br>
>><br>
><br>
><br>
</div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> es-discuss mailing list<br>
> <a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
><br>
<br>
<br>
<br>
--<br>
    Cheers,<br>
    --MarkM<br>
</div></div></blockquote></div><br></div>