> On Dec 22, 2015, at 2:44 PM, Guillaume Lessard via swift-evolution > <[email protected]> wrote: > > >> On 22 déc. 2015, at 14:03, Kevin Ballard via swift-evolution >> <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
