Feature #16037
open
Allow multiple single/double-splatted variables in `in` pattern matching and introduce non-greedy-splatted variables
Description
Pattern matching in in argument seems to prohibit multiple occurrences of single/double-splatted variables.
case ["a", "b", 3, "c", "d"]; in *foo, Integer, bar; end # >> (Not SyntaxError)
case ["a", "b", 3, "c", "d"]; in *foo, Integer, *bar; end # >> SyntaxError: unexpected *
However, unlike conventional constant/variable assignment, it makes sense to have multiple occurrences of single/double-splatted variables in a single pattern matching provided that we have a definite rule regarding whether the splats are greedy or not.
I propose the following.
- Relax the syntax for pattern matching in
inargument to allow multiple occurrences of single/double-splatted variables, and set up a rule regarding whether the splats are greedy or not; preferably greedy. - Further, introduce new syntax for non-greedy splats
*?foo,**?foo. Currently, they are syntactically invalid, so I don't think they would conflict with existing code.
case ["a", "b", 3, "c", "d", 6, "e", "f"]; in *foo, Integer, *bar; foo end # => ["a", "b", 3, "c", "d"]
case ["a", "b", 3, "c", "d", 6, "e", "f"]; in *?foo, Integer, *bar; foo end # => ["a", "b"]
Updated by sawa (Tsuyoshi Sawada) over 5 years ago
- Subject changed from Allow multiple single-splatted variables in `in` pattern matching and introduce non-greedy-splatted variables to Allow multiple single/double-splatted variables in `in` pattern matching and introduce non-greedy-splatted variables
Updated by shevegen (Robert A. Heiler) over 5 years ago
Hmm.
Syntax considerations aside (matz can evaluate whether the syntax makes sense
or not), I think an important question is how much complexity should be used or
leveraged into pattern matching in general. This is, IMO, a design decision for
matz to make. I am not the main target audience since I don't really use pattern
matching, so I am the wrong person to ask - but pattern matching seems quite
complex to me. It should be considered how much complexity will be in pattern
matching.
By the way, the syntax **? feels a bit weird to me. I think I understand where
you come from with this (possibly the use of ? in a regex, I think), but the
general complexity should also be considered, even if more flexibility may
mean more power to the ruby user at hand. That is just my personal opinion
though - it is not meant as a discouragement at all.