<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 22 Jul 2016, at 16:54, Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><br class="Apple-interchange-newline">On Jul 22, 2016, at 9:48 AM, Karl via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 22 Jul 2016, at 03:32, Robert Widmann via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 21, 2016, at 6:19 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">This is nice. Is `areSame()` being proposed because static `==` is the status quo and you're trying to make the point that `==` in the future need not guarantee the same semantics?</div></div></blockquote><div class=""><br class=""></div><div class="">Yep! &nbsp;Equivalence and equality are strictly very different things.</div><br class=""></div></div></div></blockquote></div><br class=""><div class="">As I understand it:</div><div class=""><br class=""></div><div class="">-&gt; what we call “Equatable” today checks for equivalence. For value types, equivalent is the same as equality (that’s why they are values - two instances with the same data are indistinguishable).</div><div class="">-&gt; For reference types, we have an instance-equality operator (===) which checks for what I believe you mean by equality.</div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Except that the standard floating point == is not an equivalence relation. &nbsp;I’m not sure if the distinction introduced by this proposal is solely due to that or if there are other example use cases for making a distinction.</div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">Karl</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></blockquote></div><br class=""><div class="">If it is literally just that one FloatingPoint case, then should decide which FloatingPoint should offer as the default and offer the alternative implementation as a method on FloatingPoint (areIEEEEqual()? :P areEqualOrBothNan()?).</div><div class=""><br class=""></div><div class="">The additional benefit is that this secondary equivalence function is far more descriptive about what it is doing. I’m not sure you will really be able to write generic code which always knows whether (==/areSame) are appropriate, because the differences would be so subtle. You would really have to check on a type-by-type basis.</div><div class=""><br class=""></div><div class="">e.g.</div><div class=""><br class=""></div><div class="">func find&lt;T&gt;(_ value: T, in arr: Array&lt;T&gt;) -&gt; Array&lt;T&gt;.Index? {</div><div class=""><br class=""></div><div class="">&nbsp; &nbsp; if T is FloatingPoint {</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp;return (arr as! Array&lt;FloatingPoint&gt;).index(where: { $0.areEqualOrBothNan(value) })</div><div class="">&nbsp; &nbsp; }</div><div class="">&nbsp; &nbsp; else {</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; return arr.index(where: { $0 == value })</div><div class="">&nbsp; &nbsp; }</div><div class="">}</div><div class=""><br class=""></div><div class="">Or something better without casting and with overloads for generic constraints…</div><div class=""><br class=""></div><div class="">Karl</div></body></html>