- ruby-core - ml.ruby-lang.org

[ruby-core:125692] [Ruby Bug#22103] Constant-folded /o regexp crashes with dupstring of a Regexp
by shugo (Shugo Maeda) 12 Jun '26

12 Jun '26

Issue #22103 has been reported by shugo (Shugo Maeda). ---------------------------------------- Bug #22103: Constant-folded /o regexp crashes with dupstring of a Regexp https://bugs.ruby-lang.org/issues/22103 * Author: shugo (Shugo Maeda) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- A `/o` (once) regexp whose interpolation folds to a constant crashes at runtime: ```ruby def m; /#{"a"}/o; end m #=> [BUG] heap_idx_for_size: allocation size too large ``` A plain `/#{"a"}/` (no `/o`) is fine. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125718] [Ruby Feature#12639] Speed up require in RubyGems by 5x
by hsbt (Hiroshi SHIBATA) 12 Jun '26

12 Jun '26

Issue #12639 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed The performance gap this patch targeted has been mostly eliminated by incremental optimizations in RubyGems since 2016. Running the benchmark in the description on current master shows 1.47x (about 80ns per call) instead of 5x, because the require hook now returns early when there are no unresolved dependencies. Additionally, since RubyGems 3.5, Bundler disables the require decoration entirely after bundler/setup via Gem.discover_gems_on_require. The remaining overhead is too small to justify adding a new C API, so I'm closing this issue. ---------------------------------------- Feature #12639: Speed up require in RubyGems by 5x https://bugs.ruby-lang.org/issues/12639#change-117585 * Author: segiddins (Samuel Giddins) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- This patch makes requiring an already-loaded file approximated 5x faster when the RubyGems mixin for require is present. Benchmarked via the following script: ~~~ ruby require "rubygems" require "benchmark/ips" Benchmark.ips do |x| x.report("ruby") { gem_original_require "rubygems" } x.report("rubygems") { require "rubygems" } x.compare! end ~~~ I understand that it's not ideal to add new global functions, and I'd appreciate guidance on where else I could expose this functionality to ruby code. Thanks :) ---Files-------------------------------- feature_loaded.patch (1.85 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125717] [Ruby Feature#13508] How remove/refactor code related mathn library.
by hsbt (Hiroshi SHIBATA) 12 Jun '26

12 Jun '26

Issue #13508 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed All the items in this ticket have been resolved. The mathn-specific code in array.c, complex.c, rational.c and enum.c was removed at https://github.com/ruby/ruby/commit/b958e2add835d62c0a62edaf9a23ecbbd70a3635 (https://github.com/ruby/ruby/pull/3691) and the obsolete `--enable-mathn` configure option was removed at https://github.com/ruby/ruby/commit/89110b27437d4a84f7cb0387e59fd40d94efee1d. `lib/cmath.rb` was removed from the ruby repository at https://github.com/ruby/ruby/commit/a3b85016149f4f73f08c739626b2f02badd5ad17. The mathn workaround remaining in the cmath gem is intentionally kept for compatibility with the mathn gem. ---------------------------------------- Feature #13508: How remove/refactor code related mathn library. https://bugs.ruby-lang.org/issues/13508#change-117584 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I removed mathn library at r58413 and r58432. I have some concerns related mathn library. This issue is reminder for this concern. 1. Still remains conditions for mathn loaded. ex. https://github.com/ruby/ruby/blob/trunk/array.c#L5755 2. {complex,rational}.c have {nucomp,nurat}_canonicalization methods for mathn. 3. lib/cmath.rb have workaround code for mathn see. https://github.com/ruby/ruby/blob/trunk/lib/cmath.rb#L27 I continue to discuss concerns to @mrkn -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125716] [Ruby Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by koic (Koichi ITO) 12 Jun '26

12 Jun '26

Issue #18915 has been updated by koic (Koichi ITO). Thank you for taking the time to discuss this at the dev meeting. I realized that I had overlooked one issue. I found some existing code that defines `AbstractMethodError` with a superclass other than `ScriptError`. The impact on proprietary code is unknown, but a GitHub search shows the following results: https://github.com/search?q=%2Fclass+AbstractMethodError%2F+language%3ARuby… Not all of these define a top-level `AbstractMethodError`. For example, GitLab defines `Gitlab::AbstractMethodError` as a subclass of `Exception` within its own module namespace: https://gitlab.com/gitlab-org/gitlab/-/blob/v18.10.8-ee/lib/gitlab/abstract… However, for a top-level `AbstractMethodError`, a `TypeError` due to a superclass mismatch could occur depending on the superclass used by existing code. One possible path forward would be for applications and gems to migrate during Ruby 4.1-dev. That said, if such updates are not made, users may encounter compatibility issues. Given this, it seems worth considering whether to proceed with introducing the new class in Ruby 4.1. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-117583 * Author: Quintasan (Michał Zając) * Status: Open ---------------------------------------- # Abstract Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception # Background `NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html) However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing) However I have seen this being discussed numerous times: * https://github.com/rubocop/ruby-style-guide/issues/458 * http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/ * https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd… * https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of) * https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`) * https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-… # Proposal Create `NotImplementedYetError` exception OR Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities # Evaluation ### Add `NotImplementedYetError` I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception. ### Change scope of `NotImplementedError` This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever. ---Files-------------------------------- not-implemented-error-docs.patch (1.57 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125156] [Ruby Feature#21972] Add Date.birthday and Date.age to track Ruby's milestones
by jinroq (Jinroq SAITOH) 12 Jun '26

12 Jun '26

Issue #21972 has been reported by jinroq (Jinroq SAITOH). ---------------------------------------- Feature #21972: Add Date.birthday and Date.age to track Ruby's milestones https://bugs.ruby-lang.org/issues/21972 * Author: jinroq (Jinroq SAITOH) * Status: Open ---------------------------------------- Since its inception in 1993, Ruby has grown beyond a mere programming language to become a rich culture beloved by developers worldwide. However, the standard `date` library surprisingly lacks a formal interface to commemorate Ruby's own historical milestones. The fact that developers cannot programmatically reference Ruby’s heritage is a missed opportunity to foster affection and respect for the language's identity. To rectify this historical oversight, I propose adding the following methods to reference Ruby's key anniversaries and calculate the elapsed years. #### New Features * **`Date.birthday(version = nil)`** Returns the "birthday" of significant moments in Ruby's history. * `nil` (default): **1993-02-24** (The day the name "Ruby" was decided). * `0.95`: **1995-12-21** (The first public release date). * `1.0`: **1996-12-25** (The first stable release date). * **`Date.age(version = nil)`** Calculates the current age (in full years) based on today's date and the specified milestone. * `Date.age`: Years since the name "Ruby" was born. * `Date.age(0.95)`: Years since Ruby was first introduced to the public as OSS. * `Date.age(1.0)`: Years since Ruby began its journey as a stable language. #### Usage Example ```ruby # Check the "age" of each edition puts "Name age: #{Date.age}" # => 33 (as of 2026) puts "OSS age: #{Date.age(0.95)}" # => 30 puts "Stable: #{Date.age(1.0)}" # => 29 # Perform a special action on a specific anniversary if Date.today == Date.birthday(1.0) celebrate_stable_anniversary! end ``` #### Implementation and Testing The attached patch (`birthday_and_age.patch`) includes the implementation of these methods along with a rigorous test suite (`test/date/test_date_birthday.rb`). The tests cover argument dispatching, `ArgumentError` for invalid inputs, and edge cases for age calculation (e.g., boundaries before and after the actual birthday), ensuring production-level quality. Equipping Ruby with the intelligence to reflect upon its own origins is a vital step toward the next 30 or 40 years of its evolution. (Note: This proposal was submitted on a special day that encourages looking at our history with both deep respect and a touch of creative imagination, as is traditional for such a significant date in the calendar.) ---Files-------------------------------- birthday_and_age.patch (8.08 KB) -- https://bugs.ruby-lang.org/

5 8

[ruby-core:125157] [Ruby Feature#21973] Smile argument
by kinoppyd (Yasuhiro Kinoshita) 11 Jun '26

11 Jun '26

Issue #21973 has been reported by kinoppyd (Yasuhiro Kinoshita). ---------------------------------------- Feature #21973: Smile argument https://bugs.ruby-lang.org/issues/21973 * Author: kinoppyd (Yasuhiro Kinoshita) * Status: Open ---------------------------------------- Ruby makes us smile. So I want Ruby to smile too, and that is why I would like to propose this feature. The smile argument makes Ruby smile by allowing a method call to end its argument list with `:)`. smile_method(arg, :) This syntax implicitly supplies keyword arguments by matching the names of local variables in the current scope with the names of the method’s keyword parameters. For example, if a method has the following signature: ```ruby some_method(arg, smile:, hugging:) ``` then these two calls would be equivalent: ```ruby arg = "hello" smile = "smile" hugging = "hugging" some_method(arg, smile:, hugging:) ``` ```ruby arg = "hello" smile = "smile" hugging = "hugging" some_method(arg, :) ``` The motivation behind this feature is the assumption that names used in a method signature are often also used at the call site. For instance, if a library method defines keyword arguments like `(from:, to:)`, I expect that code using that method would often have local variables named `from` and `to` holding the actual values before passing them along. In real application development, when developers adopt a new library, they will usually look at the argument list of the method they want to call. If they intend to use that method as designed, it seems natural that they may also choose the same variable names as those in the method signature. This idea was inspired by Scala’s implicit parameters. It is not exactly the same feature, but as a lazy person, I find the idea of context-driven currying quite appealing. In any case, the real purpose is to make Ruby smile. Happy Ruby! And happy April Fools' Day! -- https://bugs.ruby-lang.org/

4 3

[ruby-core:125572] [Ruby Bug#22080] `Integer(obj, exception: false)` raises when `to_str` doesn't return String
by Earlopain (Earlopain _) 11 Jun '26

11 Jun '26

Issue #22080 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #22080: `Integer(obj, exception: false)` raises when `to_str` doesn't return String https://bugs.ruby-lang.org/issues/22080 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-23T13:04:55Z master 6c6df00bbc) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```rb obj = Object.new def obj.to_str = 1 Integer(obj, exception: false) # can't convert Object to String (Object#to_str gives Integer) (TypeError) ``` But returning the wrong type from `to_int` is fine: ```rb obj = Object.new def obj.to_int = "1" Integer(obj, exception: false) # nil ``` Doc says this (https://docs.ruby-lang.org/en/master/Kernel.html#method-i-Integer) > With exception given as false, an exception of any kind is suppressed and nil is returned. So it looks like it should not raise in both cases. Or more specifically, try `to_i` next, since that is what happens when `to_int` returns the wrong type. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125701] [Ruby Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by matz (Yukihiro Matsumoto) 11 Jun '26

11 Jun '26

Issue #18915 has been updated by matz (Yukihiro Matsumoto). Thanks for the discussion, and thanks to @koic for summarizing what we talked about at RubyKaigi in Matsue. Let me settle the direction. The new exception class should inherit from `ScriptError`, not `StandardError`. Failing to define a method that a subclass is required to provide is a problem in the program itself, the same kind of problem as `SyntaxError` or `LoadError`, not a runtime error. `NotImplementedError` already inherits from `ScriptError`, so the new class becomes its natural sibling, and a clean migration target for the code that has been misusing `NotImplementedError`. This also resolves the concern raised earlier in this thread. Since it does not inherit from `StandardError`, a bare `rescue` will not swallow it and the mistake surfaces during development, while test frameworks that rescue `Exception` (such as Minitest) will still catch and report it. For the same reason I do not want to reuse `NoMethodError`, which inherits from `StandardError` and would be caught by a bare `rescue`. For the name, the candidates were `AbstractMethodError` (from Java) and `SubclassResponsibility` (from Smalltalk). `SubclassResponsibility` expresses the intent well, and the lack of an `Error` suffix would not be a problem by itself, since Ruby has exception classes such as `Interrupt` that do not end in `Error`. But because the closely related `NotImplementedError` has the `Error` suffix, I prefer to keep it consistent. Let's go with `AbstractMethodError`. Matz. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-117562 * Author: Quintasan (Michał Zając) * Status: Open ---------------------------------------- # Abstract Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception # Background `NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html) However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing) However I have seen this being discussed numerous times: * https://github.com/rubocop/ruby-style-guide/issues/458 * http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/ * https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd… * https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of) * https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`) * https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-… # Proposal Create `NotImplementedYetError` exception OR Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities # Evaluation ### Add `NotImplementedYetError` I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception. ### Change scope of `NotImplementedError` This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever. ---Files-------------------------------- not-implemented-error-docs.patch (1.57 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125664] [Ruby Feature#22100] Native Union Types in Ruby
by bogdan (Bogdan Gusiev) 11 Jun '26

11 Jun '26

Issue #22100 has been reported by bogdan (Bogdan Gusiev). ---------------------------------------- Feature #22100: Native Union Types in Ruby https://bugs.ruby-lang.org/issues/22100 * Author: bogdan (Bogdan Gusiev) * Status: Open ---------------------------------------- ## Summary Add a `UnionType` class to Ruby's standard library and extend `Class#|` to construct one, enabling expressive, composable type-checking syntax throughout the language. ```ruby String | Integer # => UnionType(Integer | String) value.is_a?(String | Integer) case value when String | Integer then ... end ``` ## Motivation ### 1. Type-checking sugar that every Ruby developer already writes by hand Runtime type validation is ubiquitous in Ruby codebases. The current idioms are verbose and inconsistent: ```ruby # Common patterns in the wild today raise TypeError unless value.is_a?(String) || value.is_a?(Integer) raise TypeError unless [String, Integer].any? { |t| value.is_a?(t) } raise TypeError unless String === value || Integer === value ``` A union type collapses all of these into a single, readable expression: ```ruby raise TypeError unless value.is_a?(String | Integer) ``` This is not a niche use-case. Any method that accepts multiple types — a common pattern in Ruby's own standard library — benefits immediately: ```ruby # Hypothetical standard library def write(data) raise TypeError, "expected String or IO" unless data.is_a?(String | IO) ... end ``` The `case`/`when` integration comes for free because `UnionType` implements `===`, making union branches in `case` expressions natural and zero-cost to adopt. ### 2. RBS and Sorbet already model this concept; Ruby itself should too Ruby's own type annotation language **RBS** uses `|` for union types as first-class syntax: ```rbs def process: (String | Integer) -> void ``` **Sorbet** expresses the same idea with `T.any`: ```ruby sig { params(value: T.any(String, Integer)).void } def process(value) = ... ``` Both tools have converged on the same semantic. Having the concept in static annotations but not in runtime Ruby creates a gap: developers must translate `String | Integer` from their type signatures into verbose `is_a?` chains by hand, and the two can drift out of sync. Sorbet requires the class constant instead, and `T.nilable` only covers a single type — so a multi-type nullable needs the verbose form: ```ruby T.any(String, Integer, NilClass) # Sorbet — nil literal not accepted T.nilable(T.any(String, Integer)) # Sorbet alternative, extra nesting ``` With a native `UnionType` the expression stays flat and readable: ```ruby String | Integer | nil # UnionType — matches RBS exactly ``` **Comparison with dry-types sum types.** dry-schema uses dry-types' `|` operator for multi-type fields: ```ruby required(:value).value(Dry::Types['integer'] | Dry::Types['string']) ``` `Dry::Types['integer']` is a `Constrained<Nominal<Integer>>` object — a class check with no coercion, semantically equivalent to what `UnionType` provides. For already-typed data (parsed JSON, domain objects) a native `UnionType` would be a simpler drop-in: ```ruby required(:value).value(Integer | String) # hypothetical, with native UnionType ``` **Construction-time optimization** is also worth noting. A `UnionType` prunes redundant members at construction: `Integer | Numeric` collapses to `Numeric` immediately, so every subsequent `===` check is against the minimal set of classes. User-space code using `Array#any?` cannot do this without re-running the deduplication on every call. A native type is also a known, stable shape that the VM could treat specially in the future — the same path that gave `Integer`, `Symbol`, and `true`/`false` their fast paths. ### 3. Config-style type validation is a widespread, unsolved pattern Many Ruby libraries and frameworks define configuration schemas as plain hashes, with a `:type` key holding an array of valid classes: ```ruby # ActiveModel-style validators validates :amount, type: [Integer, Float] # Schema definitions (dry-schema, Grape, GraphQL-Ruby, etc.) params do requires :id, type: [String, Integer] optional :meta, type: [Hash, NilClass] end # Home-grown config validation SCHEMA = { timeout: { type: [Integer, Float], default: 30 }, host: { type: [String, NilClass], default: nil }, } ``` Today these arrays have no standard protocol. Each library re-implements the same loop: ```ruby Array(config[:type]).any? { |t| value.is_a?(t) } ``` A `UnionType` gives this pattern a first-class home. Libraries could accept either an array **or** a `UnionType` transparently via `===`, and authors could write schemas that are self-documenting and immediately executable: ```ruby SCHEMA = { timeout: { type: Integer | Float, default: 30 }, host: { type: String | NilClass, default: nil }, } SCHEMA.each do |key, rule| raise TypeError, "#{key} must be #{rule[:type]}" unless rule[:type] === config[key] end ``` ### 4. Literal-value sugar for the three Ruby singletons Ruby has exactly three values that are singletons of their own class: `nil` (`NilClass`), `true` (`TrueClass`), and `false` (`FalseClass`). Because the literal and the class are interchangeable conceptually, the `|` operator accepts all three as shorthand: ```ruby String | nil # => UnionType(String | nil) same as String | NilClass String | true # => UnionType(String | true) same as String | TrueClass String | false # => UnionType(String | false) same as String | FalseClass # Common real-world pattern: nullable type def greet(name) raise TypeError unless name.is_a?(String | nil) "Hello, #{name || "stranger"}!" end ``` These three are the complete set. No other Ruby literal has a distinct singleton class, so no further sugar is needed or planned. **Footgun note**: writing `nil | String` returns `true` because `NilClass#|` is the boolean OR operator. The sugar only works with the union type on the left: `String | nil`. This mirrors how Ruby already treats `nil | x` today and is a known trade-off. ## Proposed additions | Addition | Description | |---|---| | `UnionType` class | Immutable value object wrapping a sorted set of classes | | `Class#\|` | Returns `UnionType.new(self, other)`; accepts `nil`, `true`, `false` as sugar | | `UnionType#===` | Enables `case`/`when` | | `Object#is_a?` / `kind_of?` | Accept `UnionType` as argument | | `Object#instance_of?` | Accept `UnionType` as argument | | `UnionType#&` | Intersection of two union types | | `UnionType#cover?` | True if a class is covered by the union | | `UnionType` includes `Enumerable` | Full iteration over member classes | ## Reference implementation A working gem implementation is available at https://github.com/bogdan/ruby-union-type ## Compatibility `Class#|` is not currently defined in Ruby, so no existing code is broken. `Object#is_a?` is extended in a backwards-compatible way: non-`UnionType` arguments fall through to the original C implementation. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:125698] [Ruby Feature#17944] Remove Socket.gethostbyaddr and Socket.gethostbyname
by matz (Yukihiro Matsumoto) 11 Jun '26

11 Jun '26

Issue #17944 has been updated by matz (Yukihiro Matsumoto). It didn't seem like anyone was using them, and since they weren't good API to begin with (they had Perl-like design), I felt it was okay to remove them. Matz. ---------------------------------------- Feature #17944: Remove Socket.gethostbyaddr and Socket.gethostbyname https://bugs.ruby-lang.org/issues/17944#change-117559 * Author: pvalena (Pavel Valena) * Status: Open ---------------------------------------- It is marked as unsafe by our static analysis. Can it be removed now? It was deprecated in: https://bugs.ruby-lang.org/projects/ruby-master/repository/trunk/revisions/… https://bugs.ruby-lang.org/issues/13097 -- https://bugs.ruby-lang.org/

1 0