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/