3

//indexOf()
console.log([1, 2, NaN].indexOf(NaN)); //-1

//includes()
console.log([1, 2, NaN].includes(NaN)); //true

I don't get why includes can find NaN in array, while indexOf can't.

I've read that it's happening because indexOf uses strict-equality-operator internally (NaN === NaN). But as for me, there's no deffirence between strict-equality-operator and abstract equality operator when we're talking about NaN. NaN can't be equal to itself anyway.

//strict equality operator
console.log(NaN === NaN); //false

//abstract equality operator
console.log(NaN == NaN); //still false

So why is there some difference between these 2 methods?

Ivan
  • 478
  • 2
  • 13
  • 1
    Does this answer your question? [What is the rationale for all comparisons returning false for IEEE754 NaN values?](https://stackoverflow.com/questions/1565164/what-is-the-rationale-for-all-comparisons-returning-false-for-ieee754-nan-values) – Maksym Shcherban Oct 22 '21 at 16:38

1 Answers1

5

Basically, Array.prototype.indexOf uses a different equality algorithm than Array.prototype.includes.

Array.prototype.indexOf ends up using Number::equal. Which does:

  1. If x is NaN, return false.
  2. If y is NaN, return false.

While Array.prototype.includes ends up using Number::sameValueZero

Which does:

  1. If x is NaN and y is NaN, return true.

As to why does the spec allow a comparison of two different NaNs to be true, well that's up to the TC. I can only guess they made it this way as it's a convenient way to check if there's a NaN in the array.

MinusFour
  • 13,913
  • 3
  • 30
  • 39