>
> It’s very convenient for “<“ to correspond to the standard strict-weak ordering for a type where possible.
Convenient maybe. Is it advisable for a standard library feature? Doubtful.
This is about the definition of <. It means “less than”.
This is why operator overloading has a bad reputation.
Comparable (and therefore <) in Swift is already defined as the strict total order (which is a strict-weak ordering). Granted, that's actually not true for the Comparable implementation of Float, Double, and CGFloat (NaN breaks this and turns it into a partial order), but it's a convenient fiction to ignore that (especially because NaN breaks so much of existing floating-point code that it doesn't really matter all that much that it breaks Comparable too).
Given that Comparable already must be a strict total order, it makes a lot of sense to provide Comparable for the standard strict-weak ordering (i.e. strict total order) for a type whenever we can.
I'm still not sure what your actual fundamental objection here is, because the alternative is to not support Comparable at all for tuples, which doesn't help anybody.
I don’t dispute the *usefulness* of the proposed feature; I dispute its proposed *name*.
Is ordering tuples needed so often that unclear nomenclature is advisable? No!
Back to fundamentals: (slightly paraphrased from api-design-guidelines)
- Clarity at the point of use is most important.
- Clarity is more important than brevity.
- Promote clear usage.
< does *not* mean “is ordered before”.
Well yeah, it does. That is its definition. It _also_ means "is less than" when used on real numbers, but the definition of "is less than" is equivalent to "is ordered before" given the standard ordering for real numbers. But for most things beyond real numbers, "is less than" is not necessarily well-defined, whereas "is ordered before" often is. For example, the string "a" is not considered to be "less than" the string "b", but it is considered to be ordered before it.
< does *not* have a clear meaning with composite data.
isOrderedBefore is a clear name.
isOrderedBefore is exactly what the < operator is.
I know that Comparable is documented with respect to sorting; it is unfortunate. Sortable would be a better name, given the way it is documented. Note that (apart from String) the concrete Comparables in the stdlib are numbers, stand-ins for numbers (index) or entities referenced by numbers (code points). String is the salient exception.
Comparable is not defined based on sorting, it's defined based on the notion of a strict total order, which is a pretty standard way to define it (the other standard way is to define it using a strict partial order, but that removes the ability to use it for sorting; for example, the Rust language actually has two traits Ord as a strict total order and PartialOrd as a strict partial order, where PartialOrd defines < and Ord merely provides a bound for when strict total ordering is needed, such as in sorting which requires Ord instead of PartialOrd).
The proposed change would redefine < and would be against convention.
Not only does it match the existing definition of <, but it also matches the behavior of every language I know of off the top of my head that provides tuples. This includes Rust, Haskell, OCaml, Erlang, and C++.
-Kevin Ballard
···
On Tue, Dec 22, 2015, at 08:13 PM, Guillaume Lessard via swift-evolution wrote:
> On 22 déc. 2015, at 19:40, Dave Abrahams <dabrahams@apple.com> wrote: