Ruby » Ruby master

Agreed.

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

Matz.

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

Seems like so.

Matz.

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
                           ^~

That's true. Hmm.

Matz.

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.

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?

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.

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

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

+1

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.