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

[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

[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