Project

General

Profile

Feature #17260

Promote pattern matching to official feature

Added by ktsj (Kazuki Tsujimoto) about 2 months ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
[ruby-core:100371]

Description

I propose to promote pattern matching to official feature.

The current specification is basically fine, but I'd like to reconsider single line pattern matching (expr in pat) and suggest removing it once in 3.0.

Updated by matz (Yukihiro Matsumoto) about 2 months ago

Agreed.

I have a secret plan to make right hand assignment a replacement for single line pattern match. But it's another story.

Matz.

Updated by nobu (Nobuyoshi Nakada) about 2 months ago

matz (Yukihiro Matsumoto) wrote in #note-1:

I have a secret plan to make right hand assignment a replacement for single line pattern match. But it's another story.

Maybe, is this the kind of thing?

https://github.com/nobu/ruby/pull/new/assoc-pattern-matching

Updated by matz (Yukihiro Matsumoto) about 2 months ago

Seems like so.

Matz.

Updated by nobu (Nobuyoshi Nakada) about 2 months ago

It disallows assignments to other than local variables.

https://github.com/nobu/ruby/runs/1240626799#step:15:315

SyntaxError: (eval):1: syntax error, unexpected instance variable
def self.inc(x) = x + 1 => @x
                           ^~

Updated by matz (Yukihiro Matsumoto) about 2 months ago

That's true. Hmm.

Matz.

Updated by Dan0042 (Daniel DeLorme) about 2 months ago

matz (Yukihiro Matsumoto) wrote in #note-1:

I have a secret plan to make right hand assignment a replacement for single line pattern match.

I find myself liking this idea a lot.

In #13683 nobu suggested pattern matching as a replacement for v = ary.single, and while ary in [v] is conceptually elegant, ary => [v] feels a lot more intuitive. In fact, expr in pattern can feel so unintuitive that #16670 even suggested to reverse the order; but this would not be an issue if => was used instead of in.

If => does not allow the full range of pattern matching due to syntax restrictions, maybe consider a different operator like ~> or those I proposed in #16794. And perhaps ~> as rightward assignment could also be used to resolve the ambiguity of => described in #16960.

Updated by palkan (Vladimir Dementyev) about 2 months ago

ktsj (Kazuki Tsujimoto) wrote:

I propose to promote pattern matching to official feature.

The current specification is basically fine

I have a little concern regarding the potential changes to the current specification that we might need to introduce to improve the performance.
Recently, we introduced a deconstructed value caching for array patterns, which broke the previous non-documented behaviour: it was possible to return different values for #deconstruct call within the same case..in statement. Now this is fixed (and the performance is improved).

We still have the same behaviour for #deconstruct_keys (it's possible return different value for two subsequent calls of #deconstruct_keys([:a]) within the same case..in).
I believe, that for the future optimizations of hash patterns (or even more serious internal refactoring for the performance sake), we need to "fix" this edge case as well.

So, my question is: will promoting pattern matching make it harder to introduce breaking changes (even for non-documented edge cases)? And if so, don't we need to make the specification complete first, without such gray zones?

Updated by marcandre (Marc-Andre Lafortune) about 2 months ago

palkan (Vladimir Dementyev) wrote in #note-7:

I have a little concern regarding the potential changes to the current specification that we might need to introduce to improve the performance.
Recently, we introduced a deconstructed value caching for array patterns, which broke the previous non-documented behaviour: it was possible to return different values for #deconstruct call within the same case..in statement. Now this is fixed (and the performance is improved).

I'm glad to read this, I asked for just that before 👍
It's a perfectly valid constraint IMO.

I wouldn't be worried about the fact that we aren't yet caching #deconstruct_keys. I can't think of a valid use case for replying different values. We can document that this constraint is projected in the future.

Updated by palkan (Vladimir Dementyev) about 2 months ago

marcandre (Marc-Andre Lafortune) wrote in #note-8:

We can document that this constraint is projected in the future.

+1

#10

Updated by ktsj (Kazuki Tsujimoto) about 1 month ago

Good catch.

For future optimization, I will document that the number of calls to #deconstruct/#deconstruct_keys is undefined and users should not rely on current behavior.

#11

Updated by nobu (Nobuyoshi Nakada) about 1 month ago

  • Status changed from Open to Closed

Applied in changeset git|52c630da004d9273e8e5fc91c6304e9eed902566.


Assoc pattern matching (#3703)

[Feature #17260] One-line pattern matching using tASSOC

R-assignment is rejected instead.

Also available in: Atom PDF