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

[Dave Abrahams]

> On Dec 22, 2015, at 2:44 PM, Guillaume Lessard via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> 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!

Yes, the mathematical definition of lexicographical order (the only definition that can apply here) is the same everywhere.

> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave