[swift-evolution] [Review] Tuple comparison operators (was: Add a Lazy flatMap for Sequences of Optionals)

[Dave Abrahams]

> On Dec 22, 2015, at 10:39 AM, Guillaume Lessard <glessard at tffenterprises.com> wrote:
> 
> I wholeheartedly support the Equatable (==) portion of this proposal.
> I’m quite negative about the Comparable portion; it doesn’t really make sense.
> 
> The justification for making Tuples comparable pretty much consists of hand-waving.
> Why should (0,3,4) be smaller than (0,5,0)? Beats me.
> Why would it be the other way around? Also beats me.

So that there’s a default sort order, e.g. in case you want to unique them.  Lexicographical ordering by component is the natural choice, IMO.

> I can vaguely see the utility of Comparable when I squint, but the actual behaviour would require extensive documentation with caveats about it not really making any sense. To overload an operator with a clear meaning with a behaviour with a wishy-washy definition is a bad idea.
> 
> 
> * Is the problem being addressed significant enough to warrant a change to Swift?
> 
> Yes for Equatable.
> No for Comparable.
> 
> 
> * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes for Equatable.
> No for Comparable.
> 
> 
> * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 
> I have used Mathematics during an extensive education in Physics and Engineering, at the end of which I escaped with a Ph.D. from a major institution.
> 
> Making arbitrary Tuples Equatable when possible makes sense.
> Making them Comparable absolutely does not.
> 
> Comparability is domain-specific. The standard library cannot know what an arbitrary Tuple means.

That’s why we have versions of sort et. al. that take custom comparison closures.

> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> I drew upon my experience. While I feel it’s on solid footing, I would hesitate to call it an in-depth study.
> 
> 
> Finally, I would like to note that I would support a free-standing function with a clear name that does the same thing as the proposed overloads of the comparison operator.
> 
> Sincerely,
> Guillaume Lessard
> 

-Dave