Feature #17260
closedPromote pattern matching to official feature
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 4 years 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 4 years 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 4 years ago
Seems like so.
Matz.
Updated by nobu (Nobuyoshi Nakada) about 4 years 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 4 years ago
That's true. Hmm.
Matz.
Updated by Dan0042 (Daniel DeLorme) about 4 years 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 4 years 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 4 years 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 samecase..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 4 years ago
marcandre (Marc-Andre Lafortune) wrote in #note-8:
We can document that this constraint is projected in the future.
+1
Updated by ktsj (Kazuki Tsujimoto) about 4 years 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.
Updated by nobu (Nobuyoshi Nakada) about 4 years 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.
Updated by ktsj (Kazuki Tsujimoto) almost 4 years ago
- Related to Feature #14912: Introduce pattern matching syntax added