<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 24, 2017 at 11:44 PM, David Waite 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">I still think this is a naming conflict more than anything else.<br>
<br>
The first expectation is that equatable and comparable provides strict equality and strict total ordering, and that those are exposed via operators. The other expectation is that floating point abides by the IEEE rules which have neither of these, and are exposed via operators.<br>
<br>
Either:<br>
1. the operators need to do different things in different contexts<br>
2. we need different methods/operators to indicate these different concepts<br>
3. Equatable and comparable need to be altered to no longer require strict equality and strict total ordering (and all generic algorithms based on equatable/comparable need to be checked that they still work)<br>
4. floating point numbers need to explicitly not be equatable/comparable to prevent their usage in generic algorithms requiring strict behavior.<br>
5. We break away from IEEE behavior and provide only strict equality and strict total ordering<br>
<br>
(I tried to sort these roughly in order of feasibility)<br>
<br>
Are there any other options?<br></blockquote><div><br></div><div>Have Double and Float do #5, and new types IEEEDouble and IEEEFloat implement IEEE behavior and not be suitable for use with generic algorithms when NaNs are present.</div><div><br></div></div></div></div>