Today you can pattern match records with a subset of the record's fields, e.g.
{foo} = {bar: 1, foo: 2}
or
when {bar: 1, foo: 2} is
{foo} -> ...
moreover you can have functions that generalize over the shape of a record, e.g. \r -> r.foo indexes any record with a field "foo".
I think the second is useful for tuples too, but I don't think it's a good semantics for tuples. For example, neither of these seems intentional:
(x, y) = (1, 2, 3)
when (x, y, z) is
(x, y) -> ..
and is probably more indicative of a bug. The same might sometimes be true for records, but in tuples it's more pronounced since the fields of a tuple are not named.
The suggestion is to remove such semantics for tuples.
What do folks think?
I agree that looks weird. in pattern matches I think tuples should behave more like a tag Triple a b c
where you cannot pattern match on just a subset of the fields of the tag
iirc the idea was to build "extensible tuples" so we could get more useful functions Tuple.first matching any tuple size, right? If that doesn't apply to pattern matching then how would the user create extensible-tuple functions themselves?
maybe this could be made explicit in the pattern matching?
when tuple is
(a,b) -> "I have two items"
(a,b)* -> "I have two or more items"
(wouldn't the same be valuable for records too?)
we can re-use the .. syntax from lists?
so first = \(x, .. ) -> x
I believe under the hood this maps exactly to the ext parameter on the tuple - so (a,b)* would make the most sense to me.
in the type, sure, but for pattern syntax .. has precedent
37 messages were moved from this topic to #ideas > Tuple rest patterns by Ayaz Hafiz.
:thumbs_up: I'm on board with the (x, ..) syntax
Last updated: Jun 16 2026 at 16:19 UTC