Feature #20070: commas in pattern match

• Status: Open
• Assignee: -
• Target version: -

[Dan0042 (Daniel DeLorme)]

In pattern matching, case v; in 1,2,3 is a synonym for case v; in [1,2,3]

This is the one thing that keeps confusing me, that I haven't been able to get used to. Because I'm used to case v; when 1,2,3 it feels like case v; in 1,2,3 should have a similar meaning. So it's possible to omit the square brackets but honestly I don't see much point for that, it just makes it look to me like something it is not.

In other words, I feel it would be far more intuitive (at least to me) if

case v
in 1,2,3

was a synonym for

case v
in 1
in 2
in 3

or possibly a synonym for

case v
in (1|2|3)

which would make it similar to the syntax in rescue A, B, C => err

Is it too late to change this?

[zverok (Victor Shepelev)]

I don't think it would be possible to keep consistency: the difference from case/when habits is conscious, due to the deconstruction (and that's why we needed another keyword, not improvement to when handling). If , meant alternatives for array-like patterns, what about hash-like ones? E.g.

case params
in name:, role: # that's not alternatives, right?

Another thing to get used to this convention is thinking about right-hand assignment:

# This always worked
a, b = [1, 2]
# This works with PM now: a list of patterns, not alternatives for one value
[1, 2] => a, b

This is indeed inconsistent with when and rescue, but I don't think there is a good way to reconciliate it (I am though thinking that maybe some slow future changes to the rescue can be made, to "truly" pattern-match against errors, but I am not sure yet).

[Dan0042 (Daniel DeLorme)]

I understand what you mean but this is not about keeping strict consistency per se. It's a specific case that I find confusing because it does something different from what it looks like to me, based on my personal experience.

case params
in name:, role: # that's not alternatives, right?

It's not alternatives? I guess so, but what it does is not intuitively obvious to me. I would write that code as in {name:, role:} to avoid confusion. But you make a good point; there's no equivalent when clause so interpreting it as alternatives might be just as confusing.

My confusion has to do when commas are used at the "top level" of case..in, not so much with => and right-hand assignment. Note that if you put [1, 2] => a, b inside a case..in it has a considerably different meaning:

v = [[1,2],3]
case v 
in [1, 2] => a, b
  p a=>b
end #=> {[1, 2]=>3}

The above behavior becomes clearer (imho) when you write the brackets:

v = [[1,2],3]
case v 
in [[1, 2] => a, b]
  p a=>b
end #=> {[1, 2]=>3}

[Dan0042 (Daniel DeLorme)]

zverok (Victor Shepelev) wrote in #note-1:

I am though thinking that maybe some slow future changes to the rescue can be made, to "truly" pattern-match against errors, but I am not sure yet.

A bit off-topic but I also did some thinking about this and came to the conclusion the rescue syntax is too incompatible with pattern matching. We'd have to introduce a rescue in syntax in order to do stuff like rescue in Exception(message: /foobar/) => err