Comparable and FloatingPoint types

[Chris_Lattner3 (Chris Lattner)]

@scanon

There is no solution that satisfies all of these points (or even really just the last two). I think that several people on this thread are hoping for a perfect solution. It does not exist. There are tradeoffs, and we have to pick.

Completely agree with this point.

@scanon

Some options:

1. Leave things as they are. This is basically the status quo for most languages, and while it's fairly annoying, people are at least used to it, and while it causes some bugs, it has not proven to be totally catastrophic. This throws out the second and third concerns.

FWIW, I consider #1 to be the default option that we should go with unless there is something clearly better. We have had this behavior for years now and (as you say) it is highly precedented in other languages. I agree it is suboptimal, but not enough to be worth heroic solutions given where we are.

@scanon

3. Make the comparison operators total, move the IEEE 754 comparisons under new names.

I haven't carefully considered this, but what about a variant of this:

• Do not change any existing behavior.
• Introduce an new/additive <=> operator, returning less/greater/equal/unordered, which is (by default) implemented in terms of the < and == operators for a type. Floating point types would override this default implementation with the obvious impl.

This solution is nice because:

1. It does not affect source or ABI compatibility.

2. sort and specific other algorithms could (optionally) be changed to use this, incrementally fixing a bug for FP types and possibly making those algorithms more efficient. If done in time for Swift 5, this operator could might even be able to be added as a requirement for Comparable types.

3. It is additive, so it can be done at any time.

4. For users that hit surprising behavior in practice, e.g. your contains example, they can use this (along the a closure predicate) to get the behavior they want.

Have you considered an approach like this?

-Chris