<!DOCTYPE html><html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body>

    <font size="4" face="monospace">Without diving into operator

      overloading, I think you have this bit backwards:</font><br>

    <br>

    <div class="moz-cite-prefix">On 3/11/2024 6:38 PM, Stephen

      Colebourne wrote:<br>

    </div>

    <blockquote type="cite" cite="mid:CACzrW9Az22f-sGbLRdkEON3JccYV2TY74T-VNAVNHRx=43YFHg@mail.gmail.com">

      <pre class="moz-quote-pre" wrap="">== *will* be widely used as the equals operator

irrespective of the authors' wishes. Just as it is for Enum and Class

objects. This will inevitably lead to bug reports where == on two

different NaN returns false.

</pre>

    </blockquote>

    <br>

    But, this is not the case; there is no case where float== says any

    NaNs are equal to any other, even themselves.  Float== treats _all_

    NaNs as unequal, even the same NaN bit pattern, even the same

    variable (f == f).  <br>

    <br>

    The anomaly created by the proposed Object== semantics is that a

    value type with a float field may treat the two as Object==, when

    the component fields are not float==, because float== uses neither

    bitwise nor representational equivalence, regardless of NaN bit

    patterns.  But we will see such anomalies whether we pick

    representational or bitwise comparison for values, because float==

    is already weird.<br>

    <br>

  </body>

</html>