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

[ruby-core:123958] [Ruby Feature#21720] Add a native Binary Heap / Priority Queue to Ruby's Standard Library (heapify, heappush, heappop)
by rahulk501 (Rahul Kumar) 11 Jun '26

11 Jun '26

Issue #21720 has been reported by rahulk501 (Rahul Kumar). ---------------------------------------- Feature #21720: Add a native Binary Heap / Priority Queue to Ruby's Standard Library (heapify, heappush, heappop) https://bugs.ruby-lang.org/issues/21720 * Author: rahulk501 (Rahul Kumar) * Status: Open ---------------------------------------- **Title:** Add a native Binary Heap / Priority Queue to Ruby's Standard Library (`heapify`, `heappush`, `heappop`) **Problem** Ruby currently lacks a native binary heap / priority queue data structure in the standard library. Users frequently reimplement heaps manually, or install third-party gems, simply to access common operations such as: * `heapify` * `heappush` * `heappop` * efficient priority queues Meanwhile, languages like Python provide a standard `heapq` module which is widely used in algorithms, AI, scheduling, job queues, pathfinding, graph traversal, and competitive programming. Because Ruby does not include a heap implementation, developers often write ad-hoc, buggy, or inconsistent versions of a heap. This leads to fragmentation and duplication. **Proposal** Introduce a lightweight `Heap` or `BinaryHeap` class to Ruby’s standard library with the following minimal API: ```ruby heap = Heap.new(array = []) heap.push(value) heap.pop # returns smallest (min-heap) heap.peek heap.size ``` Or a module-based functional API similar to Python’s `heapq`: ```ruby Heap.heapify(array) Heap.heappush(array, value) Heap.heappop(array) ``` Both designs are simple and allow backward-compatible extension. **Why include it in the standard library?** 1. Heaps are a *fundamental data structure*—used in sorting, algorithms, scheduling, and timers. 2. Many languages include them natively (Python, C++ via STL `priority_queue`, Java, Go, Rust `BinaryHeap`). 3. Adding it reduces unnecessary reimplementations in user codebases. 4. A small heap implementation adds little maintenance burden. 5. Existing Ruby solutions (gems like `algorithms`, `priority_queue`, custom code) are not universally available and often exceed what users need. **Reference Implementation (pure Ruby, minimal example)** ```ruby module Heap def self.heapify(arr) (arr.length / 2 - 1).downto(0) { |i| sift_down(arr, i) } arr end def self.heappush(arr, value) arr << value sift_up(arr, arr.length - 1) end def self.heappop(arr) return nil if arr.empty? arr[0], arr[-1] = arr[-1], arr[0] min = arr.pop sift_down(arr, 0) min end def self.sift_up(arr, i) while i > 0 p = (i - 1) / 2 break if arr[p] <= arr[i] arr[p], arr[i] = arr[i], arr[p] i = p end end def self.sift_down(arr, i) n = arr.length loop do left = 2 * i + 1 right = 2 * i + 2 smallest = i smallest = left if left < n && arr[left] < arr[smallest] smallest = right if right < n && arr[right] < arr[smallest] break if smallest == i arr[i], arr[smallest] = arr[smallest], arr[i] i = smallest end end private_class_method :sift_up, :sift_down end ``` **Optional C implementation** If accepted, I am willing to provide a minimal C version for performance parity with other stdlib containers. **Compatibility** No breaking changes expected. Naming avoids conflict with existing libraries. **Conclusion** Adding a tiny, well-defined heap structure would strengthen Ruby’s built-in algorithmic tools, reduce duplicated code across the ecosystem, and align Ruby with other mainstream languages. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:125637] [Ruby Feature#22094] Speed up Array#join with a byte-copy fast path
by yaroslavmarkin (Yaroslav Markin) 11 Jun '26

11 Jun '26

Issue #22094 has been reported by yaroslavmarkin (Yaroslav Markin). ---------------------------------------- Feature #22094: Speed up Array#join with a byte-copy fast path https://bugs.ruby-lang.org/issues/22094 * Author: yaroslavmarkin (Yaroslav Markin) * Status: Open ---------------------------------------- ## Original idea What if we treat `Array#join(" ")`, `Array#join("\n")` and `Array#join(";")` as hot paths (as many, if not _most_ uses of `Array#join` in the wild), and see if there is anything to optimize for a single-character ASCII joiner? ## Detailed `rb_ary_join` now works in three steps. ### 1. Measure (one pass) Walk the array once to compute the total length (as before) and, at the same time, track a single flag `ascii_only`—true while every element's code range is `ENC_CODERANGE_7BIT` (and the separator is 7-bit). This is one extra flag read per element. If an element is not a `String`, fall back immediately to the existing `ary_join_0` / `ary_join_1` append path (handles `to_str`, `to_s`, nested arrays, etc.). Everything after this point knows all elements are Strings. ### 2. Decide if the result can be byte-copied A raw copy is correct only when concatenating the bytes needs no encoding negotiation. Two cases qualify: - **All content is 7-bit ASCII** (`ascii_only`). 7-bit bytes are identical under any ASCII-compatible encoding, so the result is simply 7-bit in element 0's encoding. This also covers 7-bit strings in non-UTF-8 encodings such as Shift_JIS/EUC-JP. - **Every element shares one fast-path encoding** (UTF-8 / US-ASCII / ASCII-8BIT — all ASCII-compatible with a 1-byte terminator) **and the separator is compatible** (same encoding, or 7-bit). This is checked in a short second pass that also merges the elements' code ranges. It is reached only when the array is *not* all-7-bit, so the common all-ASCII case never pays for it. This case covers all-UTF-8 text. The merged result code range is: `7BIT` if every part is 7-bit, `VALID` if some part is clean multibyte, or left `UNKNOWN` (recomputed lazily) if any part is itself `UNKNOWN`/`BROKEN`. Same-encoding concatenation makes this merge exact. Anything else—mixed encodings, multibyte Shift_JIS/EUC-JP, an incompatible separator—is not copyable and uses the existing append path. ### 3. Copy Allocate the result once, set its encoding to element 0's, then `memcpy` each separator and element into the buffer through a single cursor. Set the length once and stamp the precomputed code range (or leave it `UNKNOWN`). The output is byte-, encoding-, and code-range-identical to the previous implementation. ## Benchmarks `benchmark/array_join.yml` and `benchmark/array_join_regression.yml`, run with `benchmark-driver --repeat-count 4`; ratio = new i/s ÷ trunk i/s. MacBook Pro M1 (arm64), macOS. `" "` and `"\n"` separators measured identically; one shown. YJIT on shows the same ratios. ### All-String arrays (the target) | array length \ element bytes | 1 | 8 | 40 | |---|---|---|---| | 100 | 2.77x | 2.41x | 1.98x | | 1,000 | 2.91x | 2.52x | 2.21x | | 100,000 | 2.94x | 2.57x | 2.20x | ### Other shapes | case | ratio | |---|---| | no separator (`join`) | 2.48x | | multi-char separator (`", "`) | 2.63x | | frozen string elements | 2.58x | | all-UTF-8 multibyte text | 2.07x | | UTF-8 multibyte separator | 2.18x | | 7-bit Shift_JIS elements | ~5x (trunk uses the slow negotiating path) | | large elements, 256 B / 1 KB / 4 KB | 2.32x / 1.38x / 1.12x | ### Fallback cases (must not regress) | case | ratio | |---|---| | non-String elements (`[1,2,3]`) | 1.00x | | UTF-16 elements | 0.99x | | nested arrays | 1.00x | | Strings then a trailing non-String | 0.98x | ### YJIT on (spot check, all-String, separator `" "`) | case | ratio | |---|---| | n=1,000, 1 B | 2.93x | | n=1,000, 8 B | 2.54x | | n=100,000, 8 B | 2.61x | --- - Patch attached. - Assisted-by: Opus 4.8. ---Files-------------------------------- 0001-Speed-up-Array-join-with-a-byte-copy-fast-path.patch (13.1 KB) -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125624] [Ruby Feature#22093] Introduce `Process::ID` for process IDs returned by `Process.spawn` and `fork`
by nobu (Nobuyoshi Nakada) 11 Jun '26

11 Jun '26

Issue #22093 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22093: Introduce `Process::ID` for process IDs returned by `Process.spawn` and `fork` https://bugs.ruby-lang.org/issues/22093 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- Currently, process IDs returned by `Process.spawn` and `fork` are plain `Integer` objects. This works, but it makes common process-handling code slightly verbose and loses the opportunity to attach process-specific behavior to the returned value. For example: ```ruby pid = Process.spawn(...) _, status = Process.wait2(pid) if status.success? ... end ``` I propose introducing `Process::ID`, an Integer-like object representing a system process ID. `Process.spawn` and parent-side `Process.fork` would return `Process::ID`. `Process::ID` would provide convenience methods such as `#wait` and `#detach`. This allows process lifecycle code to be written more directly: ```ruby pid = Process.spawn(...) status = pid.wait if status.success? ... end ``` and, when the parent does not intend to wait explicitly: ```ruby pid = Process.spawn(...) pid.detach ``` ### Proposal Add `Process::ID`. `Process::ID` would: * represent a process ID * provide `#to_i` and `#to_int` * provide `#to_s` returning the decimal PID string * provide `#inspect`, like as `Process::Status` * provide `#pid` as a reader for the integer PID * provide `#wait`, returning `Process::Status` * provide `#detach`, returning `Process::Waiter` * support comparison with the underlying integer PID `Process.spawn` would return a `Process::ID` instead of an `Integer`. On platforms with `fork`, parent-side `fork` and `Process.fork` would return a `Process::ID`. The child side would keep the current behavior: `nil` for `fork` and `0` for `Process._fork`. `IO#pid` for `IO.popen` should also return the associated `Process::ID` when applicable. ### Rationale A process ID is currently represented by an `Integer`, but conceptually it is not just a number. It is a handle-like value used with process APIs such as `wait`, `waitpid`, `kill`, and `detach`. Providing a dedicated object makes common operations more discoverable and concise, while keeping compatibility through `#to_i`/`#to_int`. This is similar in spirit to `Process::Status`: process-related values can still expose primitive information, but the object itself can provide process-specific operations. `#wait` is useful when the parent wants to wait for the child and obtain its `Process::Status`: ```ruby pid = Process.spawn("ruby", "-e", "exit 0") pid.wait.success? #=> true ``` `#detach` is useful when the parent intentionally does not want to wait for the child directly, but still wants to avoid leaving a zombie process: ```ruby pid = Process.spawn("ruby", "-e", "sleep 1") waiter = pid.detach waiter.value #=> #<Process::Status: pid ... exit 0> ``` This is preferable to tying process cleanup to object finalization. A `dfree`/GC-based wait would make process reaping depend on GC timing and could unexpectedly consume the child status before explicit `Process.wait` code gets to it. `#detach` keeps the ownership transfer explicit. ### Compatibility This is a visible compatibility change because `Process.spawn(...).class` would become `Process::ID` instead of `Integer`. However, code that passes the PID to existing process APIs should continue to work because `Process::ID` provides `#to_int`. Potentially affected code is code that checks the exact class of the returned value, such as `pid.instance_of?(Integer)`, or uses type checks such as `Integer === pid`. Such code would need to treat the value as integer-like instead, for example by using `pid.to_i` when an actual `Integer` object is needed. For `Process._fork`, if it is overridden, `fork` should preserve the object returned by the overridden `_fork` on the parent side, as long as it is Integer-like. This keeps custom hooks compatible with code that returns PID wrapper objects. ### Examples ```ruby pid = Process.spawn("ruby", "-e", "exit 0") pid.class #=> Process::ID pid.to_i #=> 12345 pid.to_s #=> "12345" pid.wait #=> #<Process::Status: pid 12345 exit 0> ``` ```ruby pid = fork { exit! true } pid.class #=> Process::ID pid.wait.success? #=> true ``` ```ruby pid = Process.spawn("ruby", "-e", "sleep 1") thread = pid.detach #=> #<Process::Waiter:...> thread.value #=> #<Process::Status: pid ... exit 0> ``` ### Open questions * Should `Process::ID` include `Comparable`, or only define `<=>`? `<=>` is useful because PIDs have historically been `Integer` objects and are sometimes sorted simply to get a deterministic order, for example in `Process.waitall` results. The numeric ordering itself has no process-specific meaning, but preserving sortability is convenient. * Should `Process::ID#wait` accept the same integer flags as existing wait APIs, provide keyword arguments, or support both? Integer flags such as `Process::WNOHANG` are consistent with `Process.waitpid`, while keywords such as `nohang: true`, `untraced: true`, and `continued: true` may be more readable for a new convenience method. * Should `Process::ID#detach` simply be equivalent to `Process.detach(self)`? * Are there other process-related APIs that should return or preserve `Process::ID`? -- https://bugs.ruby-lang.org/

5 4

[ruby-core:113430] [Ruby master Feature#19633] Allow passing block to `Kernel#autoload` as alternative to second `filename` argument
by shioyama (Chris Salzberg) 10 Jun '26

10 Jun '26

Issue #19633 has been reported by shioyama (Chris Salzberg). ---------------------------------------- Feature #19633: Allow passing block to `Kernel#autoload` as alternative to second `filename` argument https://bugs.ruby-lang.org/issues/19633 * Author: shioyama (Chris Salzberg) * Status: Open * Priority: Normal ---------------------------------------- `Kernel#autoload` takes two arguments, a symbol `module` representing the constant to be autoloaded, and a `filepath` to load the constant from (with `require`). Currently, Zeitwerk has to [monkeypatch `Kernel#require`](https://github.com/fxn/zeitwerk/blob/a7c4a983df0f4e4058f32c610dac1e8b99f687da/lib/zeitwerk/kernel.rb) to fetch the loader for the file being loaded, then run the original (aliased) `require`, then run autoload callbacks. In addition to the monkeypatch, this also requires a registry (`Zeitwerk::Registry`) to map file paths to loaders, to know which loader should be used for a given autoload-triggered `require`. In fact, Zeitwerk has to _assume_ that the monkey-patched `require` call came from an autoload trigger; there is no way to really be sure of the source. If Ruby allowed passing a block as an alternative to the explicit filepath, then I think this could be improved and would eliminate the need for a monkeypatch. So something like this: ```ruby autoload(:B) do require "lib/b" # trigger callback, etc end ``` I am implementing a gem called [Im](https://github.com/shioyama/im) which is a fork of Zeitwerk, and in the case of this gem, such a feature would be even more useful. Im implements autoloads on anonymous modules by registering an autoload and then "catching" the require and converting it into a `load`, passing the module as the second argument (see [here](https://github.com/shioyama/im/blob/44ce348639a1aae563a5be7a40602761e….) This is currently quite tricky because, again, it's hard to know _where_ a `require` came from. In addition to removing the monkeypatch (inherited from Zeitwerk), Im would further benefit from the block argument because then it could simply access the module via a closure, rather than pulling it from a registry: ```ruby mod.autoload(:Foo) do load "lib/foo.rb", mod end ``` I don't know how hard or easy this would be to implement, but if there is interest in this as a feature I'd be happy to look into implementing it. -- https://bugs.ruby-lang.org/

4 16

[ruby-core:125595] [Ruby Misc#22088] DevMeeting-2026-06-11
by mame (Yusuke Endoh) 10 Jun '26

10 Jun '26

Issue #22088 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #22088: DevMeeting-2026-06-11 https://bugs.ruby-lang.org/issues/22088 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2026/06/11 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2026/06/08. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

11 10

[ruby-core:125644] [Ruby Bug#22096] Freeing a mutex locked by a fiber inside fiber scheduler can crash
by luke-gru (Luke Gruber) 09 Jun '26

09 Jun '26

Issue #22096 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #22096: Freeing a mutex locked by a fiber inside fiber scheduler can crash https://bugs.ruby-lang.org/issues/22096 * Author: luke-gru (Luke Gruber) * Status: Open * Assignee: luke-gru (Luke Gruber) * Target version: 4.1 * Backport: 4.0: REQUIRED, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- While freeing a locked mutex, if there is a waiter for the mutex it could call `rb_fiber_scheduler_unblock` which calls into Ruby code. The function `rb_mutex_unlock_th` was a footgun because it was used during normal Ruby code and also during GC. The fix is to not call this function during GC and simply remove the mutex from `th->keeping_mutexes`. [PR](https://github.com/ruby/ruby/pull/17204) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125575] [Ruby Feature#22081] Core type definition migration from `ruby/rbs` to `ruby/ruby`
by soutaro (Soutaro Matsumoto) 09 Jun '26

09 Jun '26

Issue #22081 has been reported by soutaro (Soutaro Matsumoto). ---------------------------------------- Feature #22081: Core type definition migration from `ruby/rbs` to `ruby/ruby` https://bugs.ruby-lang.org/issues/22081 * Author: soutaro (Soutaro Matsumoto) * Status: Open * Assignee: soutaro (Soutaro Matsumoto) * Target version: 4.1 ---------------------------------------- Currently, the RBS type definitions for core libraries live in the `ruby/rbs` repository. When you change a core class or method in `ruby/ruby`, the corresponding RBS type definition often needs to be updated too — but that update requires a separate PR to `ruby/rbs`, so the work cannot be completed within `ruby/ruby` alone. This is painful for Ruby core committers and contributors. To address this problem, we will move the core library type definitions to `ruby/ruby` so that you can update the RBS type definitions within the same PR. We want to get this done in Ruby 4.1. **Question:** Do you have any concerns about migrating the RBS core type definitions to `ruby/ruby`? ## Current workflow The `test-bundled-gems` CI job in `ruby/ruby` runs the core type definition tests bundled with the rbs-gem. The tests actually call core methods and validate that the arguments and return values have the expected types using `is_a?`. When you change a core library in `ruby/ruby` in a way that requires a type definition update, the `test-bundled-gems` job fails and CI turns red. At that point, you have two options: 1. **Update the RBS type definitions** by submitting a separate PR to `ruby/rbs` 2. **Skip the failing tests** by adding the test name to the `rbs_skip_tests` file (in `ruby/ruby` repository) Either way, you are forced to take some action to get CI green again. Option 1 is actually very painful in practice. The type definitions bundled with the rbs-gem correspond to the released version of Ruby, not the in-development version. As a result, PRs to `ruby/rbs` for in-development APIs often end up modifying tests rather than type definitions — wasteful and frustrating work. Some examples: https://github.com/ruby/rbs/pull/2366 https://github.com/ruby/rbs/pull/2706 ## Updated workflow We can streamline the workflow by moving the core library RBS type definitions to `ruby/ruby` repository. - We will add a directory such as `sig` to `ruby/ruby` and store files like `string.rbs` there - Ruby's CI will run tests (`test-bundled-gems`) for the RBS type definitions in `ruby/ruby` repository. If your commit changes the core library methods/classes, please update the RBS files and tests too. - Ruby 4.1 will ship with the core type definitions, which will be installed with it. The rbs-gem will load the core library type definitions shipped with Ruby. With this workflow, when `test-bundled-gems` fails, you can fix the issue directly within your `ruby/ruby` work — without leaving the repository or coordinating a separate PR — which makes updating RBS much easier. *Note:* This workflow introduces a new step — *updating the RBS type definitions* — that wasn't previously required of Ruby committers. However, it replaces the existing workaround of skipping tests or coordinating a separate PR to `ruby/rbs` just to keep CI green. And unlike that workaround, updating the RBS definitions is itself a real improvement to Ruby. We believe this trade-off is acceptable. ## Implementation plan ### What we won't do 1. We will keep rbs-gem as a bundled gem. We won't make it a default gem, default library, or Ruby built-in. rbs-gem has a C extension, and changing from a bundled gem would require significantly more work for compilation. 2. We will keep the `ruby/rbs` repository for development of the library implementation. We want to release new versions of the gem more often than Ruby's release cycle. ### File layout in `ruby/ruby` repository - Type definitions will be stored under `sig/` (e.g., `sig/core/string.rbs`) - Type definition tests will be placed under `test/sig` - The bundled version of rbs-gem will be used to test against the `sig/` type definitions and `test/sig` tests Note that the directory names are tentative. Let me know if you have an idea what the names of the directories should be. ### Installation and distribution When Ruby is installed, the core and standard library RBS type definitions will be installed alongside it. The rbs-gem will reference these bundled definitions rather than maintaining its own copy. The RBS files will be installed under something like `"#{RbConfig::CONFIG["prefix"]}/sig"`, but the exact path is not decided yet. Suggestions are welcome! *Note:* We may also want an install-time option to skip installing the RBS type definitions, for example for minimal Ruby builds where they are not needed. #### Releasing new type definitions Currently, we can release a new version of rbs-gem to update the core type definition. After this migration, we need to wait for the next Ruby release to update type definition. I think this is okay, since the core type definition is pretty stable today. ### Testing RBS type definition tests will run as part of `make test-all` in `ruby/ruby`, rather than only through `test-bundled-gems`. This ensures type definitions are validated during the standard Ruby development workflow. Note that the RBS test suite currently takes 2–3 minutes in CI, so we need to decide which development tasks should include full testing. ### Other notes - Core RBS definitions contain documentation copied from RDoc, which needs to be updated before each release. For now, @soutaro plans to do this manually. - Ruby 4.0 and earlier releases do not include RBS type definitions, so the rbs-gem releases must continue to bundle them. @soutaro will copy the type definitions from `ruby/ruby` to `ruby/rbs` at each rbs-gem release. -- https://bugs.ruby-lang.org/

5 9

[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