From: "mame (Yusuke Endoh) via ruby-core" <ruby-core@...>
Date: 2025-11-20T04:54:14+00:00
Subject: [ruby-core:123870] [Ruby Feature#21675] Advent of Pattern Matching

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


We briefly discussed this at the monthly dev meeting. While we haven't reached a consensus on whether the scope of pattern matching should be expanded in general, I would like to share one specific concern that came up during the discussion.

Specifically, we believe that the introduction of `Exception#deconstruct` requires careful consideration.

Let's consider the `Exception#deconstruct` example:

```ruby
e = Exception.new('something bad happened')
e in Exception('something bad happened')   # => true
```

This treats `#message` as the sole component. However, subclasses like `KeyError` have additional components, such as `#key`.

```ruby
ke = KeyError.new("key not found", key: :foo)
ke.key #=> :foo
```

In this case, what should `KeyError#deconstruct` return? There are two possibilities:

1. If `KeyError#deconstruct` returns `[message]` (just like `Exception#deconstruct`): We lose the ability to pattern match against the `#key` component.

2. If `KeyError#deconstruct` returns `[message, key]` (or possibly, `[message, { key: key }]`): We can use pattern matching to check the `#key`.

   ```ruby
   ke in KeyError("key not found", :foo) #=> true
   ke in KeyError("key not found", :bar) #=> false
   ```

   However, it would no longer match the parent pattern `Exception(msg)` due to an arity mismatch:

   ```ruby
   ke in Exception('key not found')      # => false
   ```

   This behavior is counter-intuitive and introduces a pitfall for users.

Therefore, `deconstruct` should generally be implemented only when the components for matching can be definitively identified and fixed, including for future subclasses.

----------------------------------------
Feature #21675: Advent of Pattern Matching
https://bugs.ruby-lang.org/issues/21675#change-115270

* Author: baweaver (Brandon Weaver)
* Status: Open
----------------------------------------
Ruby pattern matching is a very useful feature, but many of the core classes to not leverage it currently. Given this I would like to directly invest in opening PRs to add this functionality and see how many cases we can reasonably add as we approach Ruby 4.0.

I have already started here:

* `Gem::Version` - https://github.com/ruby/ruby/pull/15109
* `Net::HTTPResponse` - https://github.com/ruby/ruby/pull/15110
* `Net::HTTPGenericRequest` - https://github.com/ruby/ruby/pull/15111

But what I am currently considering looking at first are:

* `Pathname` - Path manipulation is ubiquitous. Pattern matching on path components (dirname, basename, extname)
would simplify file handling logic.
* `URI::Generic` - URL routing and parsing would benefit from matching on scheme, host, port, and path components.
* `IPAddr` - Network programming would benefit from matching on IP address components and families for filtering
and routing logic.
* `File::Stat` - File metadata inspection is common. Matching on size, mode, timestamps, and file type predicates
would simplify permission and type checks.
* `Process::Status` - Process exit status checking is verbose. Matching on exitstatus, signals, and success state
would clarify intent.
* `Addrinfo` - Socket programming would benefit from matching on address family, socket type, and IP address/port
for connection handling.
* `OpenSSL::X509::Certificate` - Certificate validation logic could be cleaner with matching on subject, issuer,
and validity dates.
* `OpenSSL::X509::Name` - Distinguished name parsing for certificate handling would benefit from component
extraction.
* `Gem::Requirement` - Complements Gem::Version for dependency management patterns.
* `Gem::Specification` - Gem metadata inspection in tooling could benefit from structured matching.

If this is of interest I will start looking for more areas as well. My goal is to make this a feature that is well supported throughout common libraries in Ruby.

We can use this issue as a potential staging ground for discussion of what else might make sense.



-- 
https://bugs.ruby-lang.org/
______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/