Tuple comparision

They are ordered lexicographically. See https://en.wikipedia.org/wiki/Lexicographical_order.

tl;dr: The word "by" comes before the word "no" in the dictionary even though "o" comes before "y".

The problem with your definition is that the operator equivalences would not make sense. We want (a < b) == !(b <= a), so that exactly one of "less", "equal" or "greater" describes the relationship between any two values.

The existing definition makes sense if you think of the tuples as hierarchical from left to right. There's nothing necessary or even natural about that, but at least it's straighforward and consistent.

Mathematically, the problem in your case is that it is not a "total" order, which means that you can say (1, "zebra") != (2, "apple"), but cannot say whether

(1, "zebra") < (2, "apple") or (1, "zebra") > (2, "apple")

If you can define a logic for this order, then you can implement a comparison.

Otherwise, no way.

Thanks for the response, my apologies, couldn't get back, was very busy week-end time.

I sort of understood that the comparision is hierarchical, hence it doesn't look convincing to accept

(1,"zebra")<(2,"apple") 

Thanks for the response.

I think we can say, apparently, that since (1)<(2) is true and ("zebra")<("apple") is false, the net result should be false, but never true, even if we consider your explanation, then why Swift interprets this as true. Am I missing anything here?

Just for the same lexographical ordering reason, ("zebra")<("apple") is false isnt't it?

Yes, ("zebra") < ("apple") evaluates to false.

Thanks for agreeing with me, thats exactly is my point. so it doesn't make sense to say that this tuple comparision is true, despite the second pair evaluating to false.

>> even looking at these strings lexographically, and looking at these comparisions from left to right

You agree that "BZ" < "CA", alphabetically, don't you? That's lexographic ordering. In tuples, that would ("B","Z") < ("C","A").

yes, understood about the lexical ordering. Dealing with tuples would be different where we do not apply this rule at each character level for strings. In the documented example, ("zebra") < ("apple") is simply false since the first comparision z<a is itself is false. Still not sure what is the justifying reason why Swift concludes this tuple comparision as true which so far sounds irrational.

Yes, you miss something.

In the logic you describe :

(1, "zebra") < (2, "apple") should be false.

But

(2, "apple") < (1, "zebra") is obviously false.

So, which is the greatest ?

Stated otherwise, if (1, "zebra") < (2, "apple") is false, then (1, "zebra") >= (2, "apple") should be true.

This is what I mean when I sayt it is not a total order but just a partial one : in the way you define <, all elements cannot be compared

Great, so is Swift concluding the comparision ((1, "z") < (2, "a")) as true by the benifit of partial acceptance since the other two scenarios i.e. ((1, "z") == (2, "a")) and ((1, "z") > (2, "a")) are obviously false and something has just to be true to conclude the mathematical equality? Just insisting because I should not put in some insane logic while coding unless completely understanding the basics. Appreciate your patience.

>> I should not put in some insane logic while coding

That's correct. But your original logic would suggest that the compiler should not provide a comparison at all, which might have been what happened. However, since there's a definition of comparison that (a) is consistent with < and >= being the same (in the opposite order) and (b) is a commonly desired outcome and (c) if you want something different you can declare a specialized set of comparison operators, what actually happened is the Swift implement the common case.

Thank you! Looks like this is something I need to be careful with, if I have to ever code with this in future and could not avoid it 🙂