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

Dmitri Gribenko gribozavr at gmail.com
Tue Dec 22 23:01:28 CST 2015

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.


(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

More information about the swift-evolution mailing list