Maybe this has been discussed before, but it would be nice if we could compare tuples, for example (1, 2) > (1, 0), it's quite a common need.
How would that work? I'm not sure I understand what dimension or how you would measure >
I think lexicographic sorting is a common default for tuples; sorting by the first element then if equal the next, as in Aurélien's example. That seems the least "surprising" to me at least.
Yes, it's commonly used in Python, and really quite handy, for example to compare versions (3, 1, 14) > (2, 9, 0), sort structured data (year, month, day), to sort events by timestamp, to use in data structures such as priority queues, and more. This lexicographical behavior is available in many other languages (Julia tuples, C++ with std::tuple, Rust tuples, etc.). I'm sure it's possible to live without it, but it would be good to have it IMHO.
I ran into it in an Exercism exercise where we have two lists of dominoes such as [(2,5), (1,3), (5,2)] and [(3,1), (2,5), (2,5)], and we must figure out that these lists are in fact identical if we ignore the order and orientation of the dominoes. One way to solve this is to start by orientating each domino so that its smallest value is on the left, then we sort the resulting lists and check whether they are equal (we can't use a set because of the duplicates).
In this example, the order doesn't really matter, we just sort the dominoes for canonicalization.
Maybe I'm not thinking of a more obvious solution, but if tuples had this comparison behaviour it would also permit a shorthand for sorting more complicated data structures. One can first map to an intermediate tuple and compare these, avoiding the explicit branching logic.
Yes, exactly. For example: patients.sort_by(|patient| (patient.age, patient.weight))
Speaking of sort_by, is there any reason for the API described in #7006 to not be implemented, since it was originally blocked by the now superseded sort ability?
We have sort and sort_with but not sort_by. Unsure about the reversed variants as opposed to inverting arguments/outputs etc.
there any reason for the API described in #7006 to not be implemented
I think that's still the plan ... I included it in https://github.com/roc-lang/roc/issues/9596
I had grand plans of knocking out the builtins in quick succession... but I've been stuck on the numerics for a while. In hindsight probably picked the hardest ones to start with.
Luke Boswell said:
there any reason for the API described in #7006 to not be implemented
I think that's still the plan ... I included it in https://github.com/roc-lang/roc/issues/9596
Had just been scanning through that list, thought I'd check before I gave it a shot is all :sweat_smile:
Let me know if you need help at all
If you spin off a Zulip Ideas thread... it would be good to clarify the new API
Last updated: Jul 23 2026 at 13:15 UTC