Issue #17411 has been updated by mame (Yusuke Endoh).


ktsj (Kazuki Tsujimoto) wrote in #note-7:
> If there were a obvious reason, I'd like to know that.

I can think of three reasons.

* (1) This feature makes an exhaustive check impossible (like a guard), which is not related to Ruby's pattern matching.
* (2) It is difficult for a compiler to generate efficient code. For example, it cannot create a jump table statically. But we already have a pinning operator, so this may not be related to Ruby.
* (3) The semantics will become very complicated when the expressions have side-effects.

For (3), I think that the evaluation order should be unspecified; expression patterns may or may not be evaluated at any time (including compilation time). Otherwise, it would be very difficult or even almost impossible to optimize pattern matching. But I'm unsure if "the evaluation order is unspecifed" is acceptable for Ruby.

----------------------------------------
Feature #17411: Allow expressions in pattern matching
https://bugs.ruby-lang.org/issues/17411#change-89616

* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Assignee: ktsj (Kazuki Tsujimoto)
----------------------------------------
Code:

```ruby
version = {name: '2.6', released_at: Time.new(2018, 12, 25)}
version in {released_at: Time.new(2010)..Time.new(2020)}
#                            ^ syntax error, unexpected '.', expecting '}'

# This works:
range = Time.new(2010)..Time.new(2020)
version in {released_at: ^range}
#=> true
```
(Fails with all versions of the pattern matching, `in`, `=>` and `case ... in`, and on Ruby 2.7 too.)

Am I missing something about the syntax?..



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>