June 2026 - ruby-core - ml.ruby-lang.org

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

08 Jun '26

Issue #18915 has been updated by koic (Koichi ITO). I had an opportunity to discuss this with @matz and @shyouhei at Matsue RubyKaigi 12, held on June 6, 2026. Below is a summary of that discussion. - Leave the current `NotImplementedError` unchanged for now. - Introduce a new exception class intended for cases where a method is expected to be defined in a subclass. - The new class should inherit from `ScriptError` (not `RuntimeError`), following the same rationale as `SyntaxError` and `LoadError`. It represents a problem with the script itself rather than a runtime error. - `SubclassResponsibility` (or `AbstractMethodError`) is a candidate name for the new `ScriptError` subclass. Additional context reflecting my understanding of the discussion, together with some personal observations. Instead of introducing a new exception class, it would also be possible to consider a different mechanism that results in a `NoMethodError`. However, there have been repeated instances of `NotImplementedError` being used in ways that do not match its intended purpose. Furthermore, AI-generated code is also sometimes seen using `NotImplementedError` incorrectly in this manner. Since this misuse of `NotImplementedError` is already widespread, the introduction of `SubclassResponsibility` would provide a migration path for such cases. For cases where `NotImplementedError` is currently being used incorrectly, the migration path would be to replace it with `SubclassResponsibility`. For existing code that is using `NotImplementedError` correctly, no changes would be necessary and those usages would remain as they are. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-117490 * 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:124888] [Ruby Bug#21927] Prism: misleading error message for forwarding in lambda argument
by nobu (Nobuyoshi Nakada) 07 Jun '26

07 Jun '26

Issue #21927 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21927: Prism: misleading error message for forwarding in lambda argument https://bugs.ruby-lang.org/issues/21927 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Assignee: prism * ruby -v: d256629bf9 * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Even in a forwarding method: ```console $ ruby --parser=prism -e 'def m(...) ->(...){}; end' -e: -e:1: syntax error found (SyntaxError) > 1 | def m(...) ->(...){}; end | ^~~ unexpected ... when the parent method is not forwarding ``` This message is proper for method arguments: ```console $ ruby --parser=prism -e 'def m() p(...); end' -e: -e:1: syntax error found (SyntaxError) > 1 | def m() p(...); end | ^~~ unexpected ... when the parent method is not forwarding ``` The message from parse.y is different; "unexpected ... in lambda argument": ```console $ ruby --parser=parse.y -e 'def m(...) ->(...){}; end' -e:1: unexpected ... in lambda argument def m(...) ->(...){}; end ruby: compile error (SyntaxError) ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:124885] [Ruby Bug#21925] Prism misparses standalone "in" pattern matching in "case/in"
by knu (Akinori MUSHA) 07 Jun '26

07 Jun '26

Issue #21925 has been reported by knu (Akinori MUSHA). ---------------------------------------- Bug #21925: Prism misparses standalone "in" pattern matching in "case/in" https://bugs.ruby-lang.org/issues/21925 * Author: knu (Akinori MUSHA) * Status: Open * Target version: 4.1 * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin23] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Prism misparses standalone `in` pattern matching in `case/in` when the left-hand side is a method call with a dot receiver ## Summary When a standalone `expr in pattern` one-line pattern match appears inside a `case/in` branch, and `expr` is a method call with a dot receiver (for example, `obj.method`), Prism incorrectly parses `in pattern` as a new branch of the outer `case/in` instead of treating it as a `MatchPredicateNode`. The parse.y parser handles this case correctly. ## Reproduction ``` $ ruby -v ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin23] ``` It also reproduces on Ruby 3.4.8 (2025-12-17 revision 995b59f666) +PRISM [arm64-darwin25]. ### Minimal script ```ruby x = "x" case x in Integer nil in String p :before x.itself in String p :after end ``` ### Command output ``` $ ruby -e ' x = "x" case x in Integer nil in String p :before x.itself in String p :after end ' :before $ ruby --parser=parse.y -e ' x = "x" case x in Integer nil in String p :before x.itself in String p :after end ' :before :after ``` ### Expected behavior (parse.y) Both `:before` and `:after` are printed. `x.itself in String` is parsed as a standalone pattern match (predicate) inside the `in String` branch. ### Actual behavior (Prism) Only `:before` is printed; `p :after` is never executed. ## Analysis Prism splits `x.itself in String` at the `in` keyword, treating `x.itself` as the last statement of the `in String` branch and `in String` as a third branch of the outer `case/in`. The following script shows how each parser interprets the `case/in` branches: ```ruby code = <<~RUBY x = "x" case x in Integer nil in String x.itself in String p :after end RUBY # Prism require "prism" ast = Prism.parse(code).value.statements.body[1] puts "Prism: conditions: #{ast.conditions.length}" ast.conditions.each_with_index do |c, i| pat = c.pattern name = pat.respond_to?(:name) ? pat.name : pat.class stmts = c.statements&.body&.map { |s| s.class.name.split("::").last } || [] puts " in[#{i}]: pattern=#{name}, body=#{stmts}" end # parse.y (Ripper) require "ripper" sexp = Ripper.sexp(code) case_node = sexp[1][1] def count_in_branches(node) return [] unless node.is_a?(Array) && node[0] == :in pattern_node = node[1] body = node[2] || [] name = pattern_node.is_a?(Array) && pattern_node[1].is_a?(Array) ? pattern_node[1][1] : pattern_node[1] stmts = body.map { |s| s[0].to_s } [{ pattern: name, body: stmts }] + count_in_branches(node[3]) end branches = count_in_branches(case_node[2]) puts "\nparse.y (Ripper): conditions: #{branches.length}" branches.each_with_index do |b, i| puts " in[#{i}]: pattern=#{b[:pattern]}, body=#{b[:body]}" end ``` Output (run with `ruby --parser=parse.y` so Ripper uses parse.y): ``` Prism: conditions: 3 in[0]: pattern=Integer, body=["NilNode"] in[1]: pattern=String, body=["CallNode"] in[2]: pattern=String, body=["CallNode"] parse.y (Ripper): conditions: 2 in[0]: pattern=Integer, body=["var_ref"] in[1]: pattern=String, body=["case", "command"] ``` Prism reports 3 branches, while parse.y reports 2. In the parse.y result, `in[1]` correctly contains both the inner expression (`x.itself in String` parsed as a standalone pattern match) and the `command` (`p :after`). In the Prism result, `x.itself` becomes the sole body of `in[1]`, and `in String` is misinterpreted as a new `in[2]` branch of the outer `case`. ## Consideration From experimentation, the issue appears to be triggered only when all of the following are true: 1. The outer `case/in` has at least two `in` branches before the affected branch. 2. The standalone `in` expression uses a dot-receiver method call as its left-hand side, such as `obj.method in Pattern`. Conditions where this behavior is not observed: - If the expression is a receiver-less call, such as `f(x) in Pattern`, the parser keeps it as a standalone pattern match. - If the receiver expression is parenthesized, such as `(obj.method) in Pattern`, the parser keeps it as a standalone pattern match. - If you assign first, such as `y = obj.method; y in Pattern`, the parser keeps it as a standalone pattern match. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:123731] [Ruby Bug#21674] Possible regression in return case in statement
by jandudulski (Jan Dudulski) 07 Jun '26

07 Jun '26

Issue #21674 has been reported by jandudulski (Jan Dudulski). ---------------------------------------- Bug #21674: Possible regression in return case in statement https://bugs.ruby-lang.org/issues/21674 * Author: jandudulski (Jan Dudulski) * Status: Open * ruby -v: 3.4.6 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Suddenly my code started failing in Ruby 3.4.6 and 3.4.7. Shortest code example: ``` ruby args = [:increased] context = Data.define(:event).new(:decreased) case args in [event] context.event in ^event end ``` In Ruby prior to 3.4.6 in returns `false` (as expected) but in 3.4.6 and 3.4.7 it returns `:decreased`. `context.event in ^event` still returns `false`. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:124474] [Ruby Bug#21831] Prism doesn't count underscores in the fraction part of rational float
by nobu (Nobuyoshi Nakada) 07 Jun '26

07 Jun '26

Issue #21831 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21831: Prism doesn't count underscores in the fraction part of rational float https://bugs.ruby-lang.org/issues/21831 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Good. ```console $ ruby3.3 -e 'p 0.1_2r.to_f' 0.12 $ ruby3.4 --parser=parse.y -e 'p 0.1_2r.to_f' 0.12 ``` Wrong. ```console $ ruby3.4 -e 'p 0.1_2r.to_f' 0.012 ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:125631] Invitation to RubyConf Community Day
by Ufuk Kayserilioglu 05 Jun '26

05 Jun '26

I am sending the message below on behalf of Rachael Wright-Munn <chaelcodes(a)gmail.com>, who is organizing the RubyConf 2026 Hack Spaces, and is CC'ed to this email. Please direct all future correspondence about the event to her. Thank you! --- Hello ruby-core! We’re reaching out to invite you to participate in Hack Spaces during RubyConf 2026, which is in Las Vegas, NV, from July 14th to 16th. Hack Spaces will take place on Day 2 of the conference (July 15th), during Community Day. Hack Spaces at RubyConf 2026 is a collaborative event dedicated to contributing to open source projects that power the Ruby ecosystem. It's an opportunity for maintainers to collaborate in person and onboard new contributors. You can learn more about this aspect of Community Day here. ( https://storage.ghost.io/c/17/0a/170a5cb5-5524-4ba0-93b6-f17fc9bacca6/conte… ) This year, we'd like to dedicate a space to working on the Ruby programming language. By creating space for cross-project, in-person collaboration between maintainers, we hope to support the open-source community and drive the next innovation in Ruby. We sincerely hope that you attend and find it valuable. We have a site dedicated to sharing information about the projects and their maintainers. We would love to feature any maintainers or contributors who are planning to attend. If you are interested in being featured on the site, please reply to this message with name, photo/avatar, job title, company name, and any socials. As a reminder, all Ruby Core members receive free tickets to RubyConf, please reach out to rubyconf(a)rubycentral.org for assistance in that regard. With appreciation, RubyConf 2026 Program Committee & Staff

1 0

[ruby-core:125083] [Ruby Misc#21960] Improve #backtrace to not confuse terminals
by svoop (Sven Schwyn) 05 Jun '26

05 Jun '26

Issue #21960 has been reported by svoop (Sven Schwyn). ---------------------------------------- Misc #21960: Improve #backtrace to not confuse terminals https://bugs.ruby-lang.org/issues/21960 * Author: svoop (Sven Schwyn) * Status: Open ---------------------------------------- The `#backtrace` of exceptions are currently printed like so: ``` /path/to/whatever.rb:8:in `/' /path/to/whatever.rb:8:in `show' (...) ``` Most terminals recognize `/path/to/whatever.rb:8` as a local file and make it clickable as "open in editor", however, some (e.g. Ghostty) include everything up to the next whitespace, in this case `/path/to/whatever.rb:8:in`. This is then used as an argument to `open` (on macOS) which will not work due to the `:in` part. There are two ways to improve this: ## Replace the colon with a space Given the existence of `#backtrace_locations` which is better suited for programmatically working with backtrace locations, it should not break things to slightly modify the `#backtrace` to look like this: ``` /path/to/whatever.rb:8 in `/' /path/to/whatever.rb:8 in `show' (...) ^^^ space instead of colon ``` ## Add OCS 8 sequences [OCS 8](https://github.com/Alhadis/OSC8-Adoption) are the `<a>` tag for terminal output. While many terminals support it, it might cause visual noise in logs and therefore would have to be an opt-in feature e.g. via a Ruby interpreter argument. -- https://bugs.ruby-lang.org/

8 17

[ruby-core:125620] [Ruby Feature#17944] Remove Socket.gethostbyaddr and Socket.gethostbyname
by Earlopain (Earlopain _) 04 Jun '26

04 Jun '26

Issue #17944 has been updated by Earlopain (Earlopain _). ruby/spec has the following test: ```rb addr = IPAddr.new('::1').hton it 'raises SocketError when the address is not supported by the family' do -> { suppress_warning { Socket.gethostbyaddr(addr, :INET) } }.should.raise(SocketError) end ``` But it doesn't raise and instead returns the following result for me: `["pi.hole", [], 2, "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01"]`. Given https://github.com/ruby/ruby/commit/41977ef59585d1ee42ffcb546aa80f071512b257, it doesn't look I am the only one this happened to. They print warnings for ~6 years now, so it seems wasted time to investigate this. Can we simply remove them now? ---------------------------------------- Feature #17944: Remove Socket.gethostbyaddr and Socket.gethostbyname https://bugs.ruby-lang.org/issues/17944#change-117472 * 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

[ruby-core:125610] [Ruby Misc#22091] Missing Regexp documentation on relative (negative) backreferences
by cryptogopher (crypto gopher) 02 Jun '26

02 Jun '26

Issue #22091 has been reported by cryptogopher (crypto gopher). ---------------------------------------- Misc #22091: Missing Regexp documentation on relative (negative) backreferences https://bugs.ruby-lang.org/issues/22091 * Author: cryptogopher (crypto gopher) * Status: Open ---------------------------------------- I found out about them elsewhere: https://idiosyncratic-ruby.com/11-regular-extremism.html#relative-back-refe…. Description below is sourced from blog linked above: Relative Back-References Back-refs can be relatively referenced from the current position via \k<-n>: "Ruby by"[/(R)(u)(by) \k<-1>/] #=> "Ruby by" -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125609] [Ruby Bug#22090] Enabling Ruby::Box breaks Marshal.load.
by joker1007 (Tomohiro Hashidate) 02 Jun '26

02 Jun '26

Issue #22090 has been reported by joker1007 (Tomohiro Hashidate). ---------------------------------------- Bug #22090: Enabling Ruby::Box breaks Marshal.load. https://bugs.ruby-lang.org/issues/22090 * Author: joker1007 (Tomohiro Hashidate) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-31T10:35:05Z master 12c8599ffa) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This is very simple. ``` ruby class Foo end f = Marshal.dump(Foo.new) Marshal.load(f) ``` # No Ruby::Box This code returns `#<Foo:0x00007fdb9c744da0>`. --- # Ruby::Box enabled This code returns "undefined class/module Foo". ``` marshal_main.rb:5:in 'Marshal.load': undefined class/module Foo (ArgumentError) p Marshal.load(f) ^ from marshal_main.rb:5:in '<main>' ``` -- https://bugs.ruby-lang.org/

1 0