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

[Guillaume Lessard]

> On 22 déc. 2015, at 14:03, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Tue, Dec 22, 2015, at 10:39 AM, Guillaume Lessard via swift-evolution wrote:
>> 
>> 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.
> 
> You're proposing that there isn't a clear reason for it to behave the way it is, but you haven't given any justification for this claim.

My job here is to disprove, not to prove. I think that the proposed definition is lacking.


> I say there is in fact a clear reason, and that reason is that lexicographical order is a pretty common assumption.

Is lexicographical order the same the world over? No! A “pretty common assumption” is a weak foundation.

As I said earlier: “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.”

In other words:
- Provide elementwiseComparison<NTupleOfComparables>(t1,t2).
- Don’t overload <

The free-standing function provides all of the desired convenience, without messing with <


>> Comparability is domain-specific. The standard library cannot know what an arbitrary Tuple means.
> 
> The standard library cannot know this for equality either.

This proposal offers a simple *and strict* definition of Equality. (Is there a stricter definition that doesn’t devolve into identity?) Anyone who needs a looser definition can re-define it for their domain.

Comparability is a different beast. Comparability makes sense with scalars. With groups of values there is a required step to map the grouping onto a scalar score, be it magnitude (like vectors) or secret sauce (like Consumer Reports scores.)

(Note that I was quite deliberate in my choice of tuples (0,3,4) and (0,5,0). As vectors: same magnitude.)


> Heck, we provide a comparison operator on strings even though the particular comparison it implements isn't always what you want (for example, it's case-sensitive and you may want case-insensitive comparison) but nobody is arguing that strings shouldn't be comparable.

I don't love using comparison operators on strings (gotchas abound), but at least the problem of alphabetizing words is taught in elementary schools. Not so for ordering arbitrary multidimensional data.

Sincerely,
Guillaume Lessard