Project

General

Profile

Feature #16037

Allow multiple single/double-splatted variables in `in` pattern matching and introduce non-greedy-splatted variables

Added by sawa (Tsuyoshi Sawada) 4 months ago. Updated 3 months ago.

Status:
Open
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:94108]

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.

  1. Relax the syntax for pattern matching in in argument to allow multiple occurrences of single/double-splatted variables, and set up a rule regarding whether the splats are greedy or not; preferably greedy.
  2. 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"]

History

#1

Updated by sawa (Tsuyoshi Sawada) 4 months 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
#2

Updated by sawa (Tsuyoshi Sawada) 4 months ago

  • Description updated (diff)
#3

Updated by sawa (Tsuyoshi Sawada) 4 months ago

  • Description updated (diff)

Updated by shevegen (Robert A. Heiler) 3 months 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.

#5

Updated by sawa (Tsuyoshi Sawada) 3 months ago

  • Description updated (diff)

Also available in: Atom PDF