<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On Nov 2, 2017, at 7:22 PM, Xiaodi Wu via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<div class=""><br class=""><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">On Thu, Nov 2, 2017 at 5:22 PM, Matthew Johnson <span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>></span> wrote:<br class=""><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 style="overflow-wrap: break-word;" class=""><br class=""><div class=""><blockquote type="cite" class=""><span class="gmail-"><div class="">On Nov 2, 2017, at 5:20 PM, Jonathan Hull via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@swift.org</a>> wrote:</div><br class="gmail-m_9196866851710290294Apple-interchange-newline"></span><div class=""><div style="overflow-wrap: break-word;" class=""><span class="gmail-">It looks like we have a good solution. Per Steve and David’s suggestions:<div class=""><br class=""></div><div class="">1) Make FloatingPoint == reflexive</div><div class=""><br class=""></div><div class="">2) Add &== to FloatingPoint for those who specifically want IEEE behavior</div><div class=""><br class=""></div><div class="">3) Add a warning + fixit to ‘a != a’ </div><div class=""><br class=""></div></span><div class="">We should take this to evolution…</div></div></div></blockquote><div class=""><br class=""></div>Looks like a winner to me.</div></div></blockquote><div class=""><br class=""></div><div class="">Again, there remain several problems with this design. In the concrete context, the syntax `&==` 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).</div></div></div></div></div></blockquote><div><br class=""></div><div>This is a real concern, which I don’t think can be dismissed easily. It’s really the only major concern that I have, however.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Again also, this design eliminates the possibility of writing a class of useful algorithms that use Numeric. It also doesn't address the problem of sorting (as NaN would still compare unordered to all other values). These are serious questions that require careful consideration.</div></div></div></div></div></blockquote><div><br class=""></div><div>What algorithms do you have in mind? You want to detect and handle NaN for a generic algorithm written against Numeric context via x != x, I assume?</div><div><br class=""></div><div>If we went down the road that I sketched out, I think we would (completely arbitrarily) order NaN after +Inf under Comparable. Anything else would be fairly inconsistent.</div><div><br class=""></div><div>Broadly I agree that if we can find some other way to make things work, we should do it, but this also isn’t a *terrible* option.</div><div><br class=""></div><div>– Steve</div></div></div></body></html>