Comparable and FloatingPoint types

[elia (Elia Cereda)]

I’ve been thinking about this for some time today. It seems clear that the current capabilities of Swift provide no (fully) satisfying solution to address the inconsistency between the < operator on FloatingPoint types and the semantics that Equatable and Comparable expect.

Protocol conformances as they exist today generate confusion when a type can conform to a protocol in multiple ways and there isn’t an obvious choice. Moreover they don’t allow to express alternative conformances at all. The same argument came up a few weeks ago in Make Numeric Refine a new AdditiveArithmetic Protocol:

@scanon

This is a big part of the reason why I personally haven't pursued adding protocols like Semigroup, Group, or Ring to the standard library. You really want to be able to say that a type together with operations conforms to these mathematical structures, rather than saying that the type does with a fixed operation. You should be able to say that (Int, +, 0) is a semi-group, but also that (Int, * , 1) is and (Int, |, 0) is. In order for these "protocols" to be useful for generic programming, you really need to be able to have a set conform repeatedly with distinct operations. We don't really have the machinery for that in Swift today, and I don't think we should try to add these structures to the standard library without it.

What if Swift had a notion of “named protocol conformances” that could be used to satisfy generic requirements only if referenced explicitly at the point of usage? Current protocol conformances, on the other hand, would become the “default” conformances to a protocol and would still be able to satisfy requirements implicitly.

FloatingPoint types would then be able to offer multiple protocol conformances to Comparable. For example, they could offer a total order that would fully respect Comparable semantics, a partial order that traps on NaNs, an order based on IEEE comparison, … Perhaps the first one would be the only one that really makes sense, but this model would still allow the others to exists. Importantly, users could add them retroactively with an extension if the standard library didn’t provide them.

I argue that in such a model FloatingPoint could offer no default conformance to Comparable at all. If you wanted to sort an array of Doubles, you would be forced to specify which order should be used and there would be no possible ambiguity with the outcome. This feels a bit drastic, but with the right ergonomics it should not increase complexity significantly while definitely improving clarity.

Is this a model that could reasonably be introduced in a future version of Swift? If yes, is there something in the language today that would prevent it from being implemented once the ABI is declared stable?

(This is the first time that I try to participate on Swift Evolution, so I could be missing something really obvious. I hope my contribution can be useful nonetheless)