<div dir="ltr">Excellent point Karl.<div><br></div><div>In my view, floating point NaN values are really quite similar to `.none`.</div><div><br></div><div>I would be interested in exploring a move *away* from the IEEE 754 handling of NaN. In particular, we could model Float and Double as optionals (maybe implicitly-unwrapped) with NaN bit-patterns indicating `.none`.</div><div><br></div><div>Or we could model *just the non-NaN values* and make undefined operations trap, among other possibilities.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="font-size:12.8px">5. Will it be considered "ok" to define a type for which `T.areSame(a, b) == true` but `a != b`? An obvious example would be Double.nan, so I assume the answer is a resounding yes.</span></blockquote><span style="font-size:12.8px"></span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">Yes, because `==` is not a protocol requirement of Equatable, so it<br></span><span style="font-size:12.8px">can have domain-specific semantics.</span></blockquote><div><br></div><div>Per <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md">SE-0091</a> the operator will be the protocol requirement.</div><div><br></div><div>Nevin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 22, 2016 at 11:06 AM, Karl via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><br><div><blockquote type="cite"><div>On 22 Jul 2016, at 16:54, Matthew Johnson <<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>> wrote:</div><br><div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><br>On Jul 22, 2016, at 9:48 AM, Karl via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On 22 Jul 2016, at 03:32, Robert Widmann via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jul 21, 2016, at 6:19 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br><div><div dir="ltr">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><br></div><div>Yep! Equivalence and equality are strictly very different things.</div><br></div></div></div></blockquote></div><br><div>As I understand it:</div><div><br></div><div>-> 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>-> 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-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Except that the standard floating point == is not an equivalence relation. 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 style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div style="word-wrap:break-word"><div><br></div><div>Karl</div></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></blockquote></div><br></div></div><div>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><br></div><div>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><br></div><div>e.g.</div><div><br></div><div>func find<T>(_ value: T, in arr: Array<T>) -> Array<T>.Index? {</div><div><br></div><div> if T is FloatingPoint {</div><div> return (arr as! Array<FloatingPoint>).index(where: { $0.areEqualOrBothNan(value) })</div><div> }</div><div> else {</div><div> return arr.index(where: { $0 == value })</div><div> }</div><div>}</div><div><br></div><div>Or something better without casting and with overloads for generic constraints…</div><div><br></div><div>Karl</div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>