[ruby-core:108480] [Ruby master Feature#18384] Pattern Match Object

Issue #18384 has been updated by kddeisz (Kevin Newton).


There are a lot of places I would use this with pattern matching. Being able to pass around an object that for sure matches something would be really useful for Syntax Tree.

I would like to see something that is a little more explicit than passing around hashes or increased syntax though. I think we can get away with introducing a method like deconstruct_keys that does the opposite. Right now when you pass an object into a case predicate, it calls deconstruct_keys or deconstruct when you match against hash or array patterns respectively. I think we could do the opposite with something like construct. For example:

```ruby
class MyMatcher
  def construct(value)
    value in { foo: 1, bar: 2 }
  end
end

case my_object
in MyMatcher.new
  # do something
end
```

In this case you would just need the convention that `construct` is called with the object that is being checked. Then you could pass around your matching objects however you wanted, like for instance passing them back to the consumer of a library to match against their own tree structures.


----------------------------------------
Feature #18384: Pattern Match Object
https://bugs.ruby-lang.org/issues/18384#change-97524

* Author: baweaver (Brandon Weaver)
* Status: Open
* Priority: Normal
----------------------------------------
Related to discussion in #18369 it might be nice to have a literal syntax for constructing a single pattern match case outside of a one-liner.

Years ago in Qo I had done this via `===` to enable syntax like this:

```ruby
list_of_people.select(&Qo[first_name: /^F/, last_name: /r$/, age: 20..40])
```

This is valid Ruby, but the pattern match syntax itself cannot be used outside of a literal match, making this impossible without syntax changes.

### Proposal

My proposal would be a case which would be very useful in predicate methods (`any?`, `all?`, etc) and triple-equals responding methods (`select`, `reject`, `grep`, etc):

```ruby
list_of_people.select(&pattern(
  first_name: /^F/,
  last_name: /r$/,
  age: 20..40 
))
```

...in which `pattern` would be substituted with a more appropriate name which I cannot think of at the moment.

### Portability

Now the reason I think this could be very interesting is the portability of patterns. Consider the potential of making a `PatternMatch` object much like a Regular Expression:

```ruby
TARGET_PERSON = PatternMatch.new(first_name: 'something')
list_of_people.select(&TARGET_PERSON)
```

As they can serve similar purposes of giving an expressive language to query against known structures I can see this making sense. The challenge is that the initialization of such an object would need to be special to accommodate the pattern matching syntax, adding more complicated parsing rules.

This behavior might be consistent with `Proc`, `RegExp`, and `Range`-like behavior.

### ActiveRecord-like

This gets very close to the classic ActiveRecord `where` pattern:

```ruby
People.where(age: 20..30)
```

### Potential Issues

Now this is not without potential issue, as must be highlighted. The first, as just mentioned, is the ActiveRecord syntax and potentially overloading that and keyword arguments:

```ruby
People.where(age: 20..30)
```

Without a clear signifier this could make parsing much more difficult.

### Current Viable Workarounds

It also must be mentioned that this is currently possible:

```ruby
list_of_people.select { _1 in { first_name: 'something' } }
```

...though the requirement of explicit braces feels a tinge verbose, I understand why they're present.

I think this is an acceptable compromise at the moment, but feel we're very close to an interesting syntactic breakthrough.



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

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