title: Bitwise NOT with NaN: why does ToInt32 convert NaN to zero?
body: <p>I normally use the double bitwise NOT (<code>~~</code>) as an alternative to <code>Math.floor</code>. Recently I found out that, when used with <code>NaN</code>, it will return <code>0</code>:</p>
  
  <p><div class="snippet" data-lang="js" data-hide="false" data-console="true" data-babel="false">
  <div class="snippet-code">
  <pre class="snippet-code-js lang-js prettyprint-override"><code>console.log(~~NaN)</code></pre>
  </div>
  </div>
  </p>
  
  <p>After some investigation I found out that, according to the <a href="http://www.ecma-international.org/ecma-262/6.0/index.html#sec-bitwise-not-operator" rel="nofollow noreferrer">ECMAScript 2015 specs</a>, the bitwise NOT uses <code>ToInt32</code> internaly...</p>
  
  <blockquote>
    <p>Let <em>oldValue</em> be ToInt32(GetValue(<em>expr</em>)).</p>
  </blockquote>
  
  <p>... which, <a href="http://www.ecma-international.org/ecma-262/6.0/index.html#sec-toint32" rel="nofollow noreferrer">by its turn</a>:</p>
  
  <blockquote>
    <p>If number is NaN, +0, −0, +∞, or −∞, return +0.</p>
  </blockquote>
  
  <p>That explains the sequence in my snippet: <code>~~NaN --&gt; ~~0 --&gt; ~-1 --&gt; 0</code>. However, to me, <code>0</code> seems to be an odd choice for <code>NaN</code>.</p>
  
  <p>My question: why did the specification choose <code>0</code> as the returned value of <code>ToInt32(NaN)</code>? One could say <em>"because NaN is falsy"</em>, but that's not the case of +∞ or −∞. I'm preferably looking for some documented ECMA explanation (which therefore would not be <em>opinion based</em>). </p>