<div dir="ltr">On Tue, Nov 14, 2017 at 2:34 PM, David Sweeris <span dir="ltr">&lt;<a href="mailto:davesweeris@mac.com" target="_blank">davesweeris@mac.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Nov 2, 2017, at 4:22 PM, Xiaodi Wu via swift-dev &lt;<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>&gt; wrote:</div><br class="m_-3276754291599723905Apple-interchange-newline"><div><div dir="ltr">On Thu, Nov 2, 2017 at 5:22 PM, Matthew Johnson <span dir="ltr">&lt;<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><div><blockquote type="cite"><span class="m_-3276754291599723905gmail-"><div>On Nov 2, 2017, at 5:20 PM, Jonathan Hull via swift-dev &lt;<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>&gt; wrote:</div><br class="m_-3276754291599723905gmail-m_9196866851710290294Apple-interchange-newline"></span><div><div><span class="m_-3276754291599723905gmail-">It looks like we have a good solution.  Per Steve and David’s suggestions:<div><br></div><div>1) Make FloatingPoint == reflexive</div><div><br></div><div>2) Add &amp;== to FloatingPoint for those who specifically want IEEE behavior</div><div><br></div><div>3) Add a warning + fixit to ‘a != a’ </div><div><br></div></span><div>We should take this to evolution…</div></div></div></blockquote><div><br></div>Looks like a winner to me.</div></div></blockquote><div><br></div><div>Again, there remain several problems with this design. In the concrete context, the syntax `&amp;==` suggests that it is a compatibility, legacy, or specialized function not to be preferred over `==`. This makes Swift deviate from every other programming language, creating a new footgun for experienced developers, and encourages a performance hit where one is not demonstrably necessary (most operations that ask about UI coordinates, say, will never have NaN as an input). Again also, this design eliminates the possibility of writing a class of useful algorithms that use Numeric. It also doesn&#39;t address the problem of sorting (as NaN would still compare unordered to all other values). These are serious questions that require careful consideration.<br></div><div><br></div><div>In initiating this conversation, my goal has been to start a conversation about possible designs for `Equatable` and `Comparable` that permis useful generic algorithms to work correctly with floating point without hampering performance or changing syntax for concrete numerics. Unless this is clearly impossible, the leap of changing the behavior of `==` for a numeric type should absolutely not be the proposed solution, in my view.<br></div></div></div></div></div></blockquote><br></div><div>What about bringing `===` into the mix? IIRC `identity`semantics aren&#39;t well-defined for value types anyway. Is there even an &quot;Identifiable&quot; protocol in the stdlib?</div></div></blockquote><div> </div><div>That is, indeed, one avenue that can be explored. (See Swift Evolution archives for more on that.) But, it is actually possible to get very close to squaring the circle here, and when I have some time I will share some drafts with the list.</div><div><br></div></div><br></div></div>