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

[Dmitri Gribenko]

On Tue, Dec 22, 2015 at 8:13 PM, Guillaume Lessard via swift-evolution
<swift-evolution at swift.org> wrote:
>
>> On 22 déc. 2015, at 19:40, Dave Abrahams <dabrahams at apple.com> wrote:
>>
>> 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.
>
> 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”.

How is "is ordered before" different from "less than"?  Can x be "less
than" y and yet be ordered after it?  No.  Thus, there is no
possibility of confusion here.  Lexicographical order is the only
reasonable definition of comparison for tuples, one can't imagine a
different definition.

It is possible that a different type with the same shape as a tuple
(say, a Point3D composed of three floating point numbers) will choose
to use a different order, or not define one at all.  But that would be
a choice made by a type used for a specific domain, not a general
tuple type without any semantics attached.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/