[swift-evolution] [pitch] Comparison Reform

[Rob Mayoff]

On Mon, Apr 24, 2017 at 11:44 PM, David Waite via swift-evolution <
swift-evolution at swift.org> wrote:

> I still think this is a naming conflict more than anything else.
>
> 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.
>
> Either:
> 1. the operators need to do different things in different contexts
> 2. we need different methods/operators to indicate these different concepts
> 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)
> 4. floating point numbers need to explicitly not be equatable/comparable
> to prevent their usage in generic algorithms requiring strict behavior.
> 5. We break away from IEEE behavior and provide only strict equality and
> strict total ordering
>
> (I tried to sort these roughly in order of feasibility)
>
> Are there any other options?
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170425/2466a9b2/attachment.html>