<div dir="ltr">On Wed, Oct 25, 2017 at 8:26 PM, Jonathan Hull <span dir="ltr"><<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>></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"><span class="">> On Oct 25, 2017, at 9:01 AM, David Sweeris via swift-dev <<a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a>> wrote:<br>
><br>
> That said, I fully acknowledge that this is all above my pay grade (also I hadn't realized that the issue was as settled as it apparently is). If splitting the protocols is a no-go from the get go, I'll go back to trying to figure out a better way to handle it without doing that.<br>
<br>
<br>
</span>I don’t think it is settled. The issue that Xiaodi mentioned was a PartiallyEq protocol which still had a signature of (T,T)->Bool. People just used that protocol instead of Equatable without taking into account the difference in behavior. The signature of (T,T)->Bool? changes things because people are forced to deal with the optional.<br>
<br>
Currently, I think we should do 3 things:<br>
<br>
1) Create a new protocol with a partial equivalence relation with signature of (T, T)->Bool? and automatically conform Equatable things to it<br>
2) Depreciate Float, etc’s… Equatable conformance with a warning that it will eventually be removed (and conform Float, etc… to the partial equivalence protocol)<br>
3) Provide an '&==‘ relation on Float, etc… (without a protocol) with the native Float IEEE comparison<br>
<br>
I think this provides several benefits. #3 allows pure speed when needed, but not in a generic context (and is appropriately scary to cause some thought). #1 forces correct handling in generic contexts. #2 gives people time to make the adjustment, but also eventually requires them to switch to using #1 or #3.<br>
<br>
I think it will cause A LOT of currently incorrect code to be fixed.<br></blockquote><div><br></div><div>One issue which occurred to me only recently, which I hadn't considered, renders my `&==` idea and all similar schemes untenable:</div><div><br></div><div>Useful algorithms can and are written which operate on both floating-point and integer numeric types. In fact, the whole point of laboriously designing `Numeric` as part of SE-0104 was to make it possible to do so. If IEEE comparison is relegated to `FloatingPoint` and the only operator remaining on `Numeric` is `==`, then not only will there be a mandatory performance hit, but currently correct algorithms can be broken with absolutely no way to express a fix.</div><div><br></div></div></div></div>