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

[ruby-core:122338] [Ruby Bug#21384] const_added is triggered twice when using autoload
by petekinnecom (Pete Kinnecom) 05 Jun '25

05 Jun '25

Issue #21384 has been reported by petekinnecom (Pete Kinnecom). ---------------------------------------- Bug #21384: const_added is triggered twice when using autoload https://bugs.ruby-lang.org/issues/21384 * Author: petekinnecom (Pete Kinnecom) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- As the title says, I've noticed that `const_added` is invoked twice when using `autoload`. I'm wondering if this behavior is intended or perhaps a bug. Here's a small script to reproduce what I'm seeing: ``` ruby require "tmpdir" dir = Dir.mktmpdir File.write( File.join(dir, "const.rb"), "class Const; end" ) def Object.const_added(const_name) super.tap { puts "const_added: #{const_name}" } end $LOAD_PATH << dir puts "before autoload call" autoload :Const, "const" puts "after autoload call" puts Const # Produces output: # # => before autoload call # => const_added: Const # => after autoload call # => const_added: Const # => Const ``` I'm seeing the behavior using the following docker containers ruby:3.2 and ruby:3.5-rc when running like so: `docker run -v ./:/home ruby:3.5-rc ruby /home/script.rb`. Thanks. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:121142] [Ruby master Misc#21154] Document or change Module#autoload?
by fxn (Xavier Noria) 05 Jun '25

05 Jun '25

Issue #21154 has been reported by fxn (Xavier Noria). ---------------------------------------- Misc #21154: Document or change Module#autoload? https://bugs.ruby-lang.org/issues/21154 * Author: fxn (Xavier Noria) * Status: Open ---------------------------------------- The documentation of `Module#autoload?` says > Returns filename to be loaded if name is registered as autoload in the namespace of mod or one of its ancestors. Cool, but in the following snippet ```ruby autoload :Foo, 'foo' autoload?(:Foo) ``` the second line could evaluate to `nil`, and this does not seem to agree. I just registered an autoload, therefore (according to the documentation) I should get "foo" back in line 2. I'd like to ask for clarification from the Ruby team: 1. Is the documentation complete? Should that second line always return "foo"? 2. If the answer is no, which is the logic missing in the docs? Thank you! -- https://bugs.ruby-lang.org/

3 31

[ruby-core:122359] [Ruby Bug#21391] Inconsistent trailing slash behavior of File#join and Pathname#join with empty strings
by lovro-bikic 05 Jun '25

05 Jun '25

Issue #21391 has been reported by lovro-bikic (Lovro Bikić). ---------------------------------------- Bug #21391: Inconsistent trailing slash behavior of File#join and Pathname#join with empty strings https://bugs.ruby-lang.org/issues/21391 * Author: lovro-bikic (Lovro Bikić) * Status: Open * ruby -v: ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [x86_64-darwin23] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby File.join('/usr', '') # => "/usr/" Pathname.new('/usr').join('').to_s # => "/usr" # no trailing slash File.join('/usr', ' ') # => "/usr/ " Pathname.new('/usr').join(' ').to_s # => "/usr/ " ``` `File.join` with an empty string adds a trailing slash, `Pathname#join` doesn't. When `Pathname#join` argument is a string with empty whitespace, a trailing slash is added (plus whitespace). I think it's a common use-case to append a trailing slash to `Pathname`, and currently you have to resort to other methods such as string interpolation (e.g. in Rails, `"#{Rails.root}/"`) or `File.join` (e.g. `File.join(Rails.root, '')`). In other popular languages, both approaches have been taken: - [`os.path.join` in Python](https://docs.python.org/3.12/library/os.path.html#os.path.join) adds a trailing slash: ```python import os os.path.join('/usr', '') # '/usr/' ``` - [Path.join in Rust](https://doc.rust-lang.org/std/path/struct.Path.html#method.join) adds a trailing slash: ```rust use std::path::{Path}; fn main() { println!("{}", Path::new("/usr").join("").display()); // prints "/usr/" } ``` - [path.join in Node](https://nodejs.org/api/path.html#pathjoinpaths) doesn't add a trailing slash: ```js const path = require('path'); path.join('/usr', ''); // '/usr' ``` - [filepath.Join in Go](https://pkg.go.dev/path/filepath#Join) doesn't add a trailing slash: ```go package main import ("fmt"; "path/filepath") func main() { fmt.Println(filepath.Join("/usr", "")) // prints "/usr" } ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:122164] [Ruby Feature#21347] Add `open_timeout` as an overall timeout option for `Socket.tcp`
by shioimm (Misaki Shioi) 05 Jun '25

05 Jun '25

Issue #21347 has been reported by shioimm (Misaki Shioi). ---------------------------------------- Feature #21347: Add `open_timeout` as an overall timeout option for `Socket.tcp` https://bugs.ruby-lang.org/issues/21347 * Author: shioimm (Misaki Shioi) * Status: Open ---------------------------------------- I propose to add an overall timeout option to `Socket.tcp` (and `TCPSocket.new`) ### Background Currently, `TCPSocket.new` and `Socket.tcp` accept two kind of timeout options: - `resolv_timeout`, which controls the timeout for DNS resolution - `connect_timeout`, which controls the timeout for the connection attempt With the introduction of Happy Eyeballs Version 2 (as per [RFC 8305](https://datatracker.ietf.org/doc/html/rfc8305)) in[ Feature #20108](https://bugs.ruby-lang.org/issues/20108) and [Feature #20782](https://bugs.ruby-lang.org/issues/20782), both address resolution and connection attempts are now parallelized. As a result, the sum of `resolv_timeout` and `connect_timeout` no longer represents the total timeout duration. This is because, in HEv2, name resolution and connection attempts are performed concurrently, causing the two timeouts to overlap. Example: When `resolv_timeout: 200ms` and `connect_timeout: 100ms` are set: 1. An IPv6 address is resolved after the method starts immediately (IPv4 is still being resolved). 2. A connection attempt is initiated to the IPv6 address 3. After 100ms, `connect_timeout` is exceeded. However, since `resolv_timeout` still has 100ms left, the IPv4 resolution continues. 4. After 200ms from the start, the method raises a `resolv_timeout` error. In this case, the total elapsed time before a timeout is 200ms, not the expected 300ms (100ms + 200ms). Furthermore, in HEv2, connection attempts are also parallelized. It starts a new connection attempts every 250ms for resolved addresses. This makes the definition of `connect_timeout` even more ambiguous—specifically, it becomes unclear from which point the timeout is counted. Additionally, these methods initiate new connection attempts every 250ms (Connection Attempt Delay) for each candidate address, thereby parallelizing connection attempts. However, this behavior makes it unclear from which point in time the connect_timeout is actually measured. Currently, a `connect_timeout` is raised only after the last connection attempt exceeds the timeout. Example: When `connect_timeout: 100ms` is set and 3 address candidates: 1. Connect to address `a` at t=0ms. 2. Connect to address `b` at t=250ms. 3. Connect to address `c` at t=500ms. 4. If all fail, the exception is raised at t=1500ms (1000ms after `c`, 1250ms after `b`, 1500ms after `a`). 1. Start a connection attempt to the address `a` 2. 250ms after step 1, start a new connection attempt to the address `b` 3. 500ms after step 1, start a new connection attempt to the address `c` 4. 1000ms after step 3 (1000ms after starting the connection to `c`, 1250ms after starting the connection to `b,` and 1500ms after starting the connection to `a`) `connect_timeout` is raised This behavior aims to favor successful connections by allowing more time for each attempt, but it results in a timeout model that is difficult to reason about. These methods have supported `resolv_timeout` and `connect_timeout` options even before the introduction of HEv2. However, in many use cases, it would be more convenient if a timeout occurred after a specified duration from the start of the method. Similar functions in other languages (such as PHP, Python, and Go) typically allow specifying only an overall timeout. ### Proposal I propose adding an `open_timeout` option to `Socket.tcp` in the following PR, which triggers a timeout after a specified duration has elapsed from the start of the method. https://github.com/ruby/ruby/pull/13368 The name `open_timeout` aligns with the existing accessor used in `Net::HTTP`. If `open_timeout` is specified together with `resolv_timeout` and `connect_timeout`, I propose that only `open_timeout` be used and the others be ignored. While it is possible to support combinations of `open_timeout`, `resolv_timeout`, and `connect_timeout`, doing so would require defining which timeout takes precedence in which situations. In this case, I believe it is more valuable to keep the behavior simple and easy to understand, rather than supporting more complex use cases. If this proposal is accepted, I also plan to extend `open_timeout` support to `TCPSocket.new`. While the long-term future of `resolv_timeout` and `connect_timeout` may warrant further discussion, I believe the immediate priority is to offer a straightforward way to specify an overall timeout. ### Outcome If `open_timeout` is also supported by `TCPSocket.new`, users would be able to manage total connection timeouts directly in `Net::HTTP#connect` without relying on `Timeout.timeout`. https://github.com/ruby/ruby/blob/aa0f689bf45352c4a592e7f1a044912c40435266/… -- https://bugs.ruby-lang.org/

3 5

[ruby-core:122228] [Ruby Feature#21359] Introduce `Exception#cause=` for Post-Initialization Assignment
by ioquatix (Samuel Williams) 05 Jun '25

05 Jun '25

Issue #21359 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #21359: Introduce `Exception#cause=` for Post-Initialization Assignment https://bugs.ruby-lang.org/issues/21359 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) ---------------------------------------- Ruby currently allows an exception’s `cause` to be explicitly set **only at the time of raising** using `raise ..., cause: ...`. However, there are valid use cases where it would be convenient to set the cause when creating an exception. ## The Problem Ruby supports exception chaining via the `cause:` keyword during a `raise`, like so: ```ruby raise StandardError.new("failure"), cause: original_exception ``` ## Proposed Solution Introduce `Exception#cause=` as a public setter method on `Exception`, allowing post-initialization assignment of the cause: ```ruby cause = RuntimeError.new("low-level error") error = StandardError.new("higher-level error") error.cause = cause ``` It would be semantically equivalent to the following implementation: ```ruby error = StandardError.new("error") cause = RuntimeError.new("cause") class Exception def cause= value backtrace = self.backtrace_locations raise self, cause: value rescue Exception self.set_backtrace(backtrace) end end p error.cause # nil error.cause = cause p error.cause # => #<RuntimeError: cause> ``` ### Benefits * Simplifies creation of rich exception objects in frameworks, tools, and tests. * Enables structured error chaining in asynchronous and deferred execution environments. * Avoids misuse of `raise`/`rescue` for control flow and metadata setting. -- https://bugs.ruby-lang.org/

4 8

[ruby-core:121700] [Ruby Feature#21279] Bare "rescue" should not rescue NameError
by AMomchilov (Alexander Momchilov) 05 Jun '25

05 Jun '25

Issue #21279 has been reported by AMomchilov (Alexander Momchilov). ---------------------------------------- Feature #21279: Bare "rescue" should not rescue NameError https://bugs.ruby-lang.org/issues/21279 * Author: AMomchilov (Alexander Momchilov) * Status: Open ---------------------------------------- # Abstract Bare `rescue` keywords (either as a modifier like `foo rescue bar` or as clause of a `begin` block) should _not_ rescue `NameError` or `NoMethodError`. This behaviour is unexpected and hides bugs. ## Background Many Rubyists are surprised to learn that [`NameError`](https://docs.ruby-lang.org/en/master/NameError.html) is a subclass of [`StandardError`](https://docs.ruby-lang.org/en/master/StandardError.html), so it's caught whenever you use a "bare" `rescue` block. ```ruby begin DoesNotExist rescue => e p e # => #<NameError: uninitialized constant DoesNotExist> end ``` Similarly, [`NoMethodError`](https://docs.ruby-lang.org/en/master/NoMethodError.html) is also rescued, because it's a subclass of `NameError`. ```ruby begin does_not_exist() rescue => e p e # => #<NoMethodError: undefined method `does_not_exist' for main> end ``` This is almost never expected behaviour. `NameError`/`NoMethodError` is usually the result of a typo in the Ruby source, that cannot be reasonably recovered from at runtime. It's a programming error just like a [`SyntaxError`](https://docs.ruby-lang.org/en/master/SyntaxError.html), which _isn't_ a `StandandError`. ## Proposal No matter the solution, solving this problem will require a breaking change. Perhaps this could be part of Ruby 4? The most obvious solution is to change the superclass of `NameError` from `StandardError` to `Exception` (or perhaps [`ScriptError`](https://docs.ruby-lang.org/en/master/ScriptError.html), similar to `SyntaxError`). ### Alternatives considered If we want to avoid changing the inheritance hierarchy of standard library classes, we could instead change the semantics of bare `rescue` from "rescues any subtype of `StandardError`", to instead be "rescues any subtype of `StandardError` except `NameError` or its subtypes". This is worse in my opinion, as it complicates the semantics for no good reason. ## Use cases <details><summary>fun example</summary> The worst case I've seen of this came from a unit tesat like so: ```ruby test "aborts if create_user returns error" do mock_user_action(data: { user: { id: 123, ... }, errors: [{ code: "foo123" }] }) ex = assert_raises(StandardError) do CreateUser.perform(123) end assert_match(/foo123/, ex.message) end ``` This test passes, but not for the expected reason. It turns out that inside of the business logic of `CreateUser`, the error code data was accessed as a method call like `error.code`, rather than a key like `error[:code]`. This lead to: ``` NoMethodError (undefined method `code' for {:code=>"foo123"}:Hash) ``` The `NoMethodError` is a `StandardError`, and even more insidious, because `foo123` is part of the NoMethodError's default message, the `assert_match(/foo123/, ex.message)` also mathches! The correct fix here would be to introduce a specific error like `UserCreationError` that can be rescued specifically, with a field like `code` that can be matched instead of the message. Regardless, this illustrates the kind of confusion that comes from `NoMethodError` being a `StandardError`. </details> # Discussion It might be useful to distinguish between `NameError`s made in "static" code like `DoesNotExist` or `does_not_exist()`, versus those encountered dynamically via `Object.const_get(dynamic_value)` or `object.send(dynamic_value)`. In those metaprogramming cases, the error could be a consequence of bad runtime data, which is more recoverable than just some fundamental error with your Ruby code. -- https://bugs.ruby-lang.org/

8 8

[ruby-core:121837] [Ruby Feature#21311] Namespace on read (revised)
by tagomoris (Satoshi Tagomori) 05 Jun '25

05 Jun '25

Issue #21311 has been reported by tagomoris (Satoshi Tagomori). ---------------------------------------- Feature #21311: Namespace on read (revised) https://bugs.ruby-lang.org/issues/21311 * Author: tagomoris (Satoshi Tagomori) * Status: Open ---------------------------------------- This replaces #19744 ## Concept This proposes a new feature to define virtual top-level namespaces in Ruby. Those namespaces can require/load libraries (either .rb or native extension) separately from other namespaces. Dependencies of required/loaded libraries are also required/loaded in the namespace. This feature will be disabled by default at first, and will be enabled by an env variable `RUBY_NAMESPACE=1` as an experimental feature. (It could be enabled by default in the future possibly.) ### "on read" approach The "on write" approach here is the design to define namespaces on the loaded side. For example, Java packages are defined in the .java files and it is required to separate namespaces from each other. It can be implemented very easily, but it requires all libraries to be updated with the package declaration. (In my opinion, it's almost impossible in the Ruby ecosystem.) The "on read" approach is to create namespaces and then require/load applications and libraries in them. Programmers can control namespace separation at the "read" time. So, we can introduce the namespace separation incrementally. ## Motivation The "namespace on read" can solve the 2 problems below, and can make a path to solve another problem: * Avoiding name conflicts between libraries * Applications can require two different libraries safely which use the same module name. * Avoiding unexpected globally shared modules/objects * Applications can make an independent/unshared module instance. * Multiple versions of gems can be required * Application developers will have fewer version conflicts between gem dependencies if rubygems/bundler will support the namespace on read. (Support from RubyGems/Bundler and/or other packaging systems will be needed) For the motivation details, see [Feature #19744]. ## How we can use Namespace ```ruby # app1.rb PORT = 2048 class App def self.port = ::PORT def val = PORT.to_s end p App.port # 2048 # app2.rb class Number def double = self * 2 end PORT = 2048.double class App def self.port = ::PORT def val = PORT.double.to_s end p App.port # 4096 # main.rb - executed as `ruby main.rb` ns1 = Namespace.new ns1.require('./app1') # 2048 ns2 = Namespace.new ns2.require('./app2') # 4096 PORT = 8080 class App def self.port = ::PORT def val = PORT.to_s end p App.port # 8080 p App.val # "8080" p ns1::App.port # 2048 p ns1::App.val # "2048" p ns2::App.port # 4096 p ns2::App.val # "8192" 1.double # NoMethodError ``` ## Namespace specification ### Types of namespaces There are two namespace types, "root" and "user" namespace. "Root" namespace exists solely in a Ruby process, and "user" namespaces can be created as many as Ruby programmers want. ### Root namespace Root namespace is a unique namespace to be defined when a Ruby process starts. It only contains built-in classes/modules/constants, which are available without any `require` calls, including RubyGems itself (when `--disable-gems` is not specified). ### User namespace User namespace is a namespace to run users' Ruby scripts. The "main" namespace is the namespace to run the user's `.rb` script specified by the `ruby` command-line argument. Other user namespaces ("optional" namespaces) can be created by `Namespace.new` call. In user namespace (both main and optional namespaces), built-in class/module definitions are copied from the root namespace, and other new classes/modules are defined in the namespace, separately from other (root/user) namespaces. The newly defined classes/modules are top-level classes/modules in the main namespace like `App`, but in optional namespaces, classes/modules are defined under the namespace (subclass of Module), like `ns::App`. In that namespace `ns`, `ns::App` is accessible as `App` (or `::App`). There is no way to access `App` in the main namespace from the code in the different namespace `ns`. ### Constants, class variables and global variables Constants, Class variables of built-in classes and global variables are also separated by namespace. Values set to class/global variables in a namespace are invisible in other namespaces. ### Methods and procs Methods defined in a namespace run with the defined namespace, even when called from other namespaces. Procs created in a namespace run with the defined namespace too. ### Dynamic link libraries Dynamic link libraries (typically .so files) are also loaded in namespaces as well as .rb files. ### Open class (Changes on built-in classes) In user namespaces, built-in class definitions can be modified. But those operations are processed as copy-on-write of class definition from the root namespace, and the changed definitions are visible only in the (user) namespace. Definitions in the root namespace are not modifiable from other namespaces. Methods defined in the root namespace run only with root-namespace definitions. ## Enabling Namespace Specify `RUBY_NAMESPACE=1` environment variable when starting Ruby processes. `1` is the only valid value here. Namespace feature can be enabled only when Ruby processes start. Setting `RUBY_NAMESPACE=1` after starting Ruby scripts performs nothing. ## Pull-request https://github.com/ruby/ruby/pull/13226 -- https://bugs.ruby-lang.org/

18 108

[ruby-core:122221] [Ruby Feature#21358] Advanced filtering support for #dig
by lovro-bikic 05 Jun '25

05 Jun '25

Issue #21358 has been reported by lovro-bikic (Lovro Bikić). ---------------------------------------- Feature #21358: Advanced filtering support for #dig https://bugs.ruby-lang.org/issues/21358 * Author: lovro-bikic (Lovro Bikić) * Status: Open ---------------------------------------- Currently, `#dig` can be used to access nested data structures using "simple" keys, such as array indices or hash keys. Real-world applications sometimes require non-trivial data access, for example, finding an item in an array based on some criteria, then returning some property of that item. This feature request is to add support for such non-trivial access to `#dig`, concretely by allowing `Proc`s as dig keys. ## Introductory example Given the following data structure (similar to one from [dig docs](https://docs.ruby-lang.org/en/3.4/dig_methods_rdoc.html)) ```ruby item = { id: '0001', batters: { batter: [ { id: '1001', type: 'Regular' }, { id: '1002', type: 'Chocolate' }, { id: '1003', type: 'Blueberry' }, { id: '1004', type: 'Devils Food' } ] } } ``` and the requirement "find ID of batter with type 'Chocolate'" (assuming we don't know its position in the array), currently the datum can be retrieved like so: ```ruby item.dig(:batters, :batter)&.find { it[:type] == 'Chocolate' }&.[](:id) # => "1002" ``` If `#dig` supported `Proc` as keys, the solution could be: ```ruby item.dig(:batters, :batter, -> { it[:type] == 'Chocolate' }, :id) # => "1002" ``` ## Implementation Here's a monkey patch which adds `Proc` support to `Array#dig`, to play around with: ```ruby class Array alias_method :original_dig, :dig def dig(key, *identifiers) case key when Proc val = find(&key) identifiers.any? ? val&.dig(*identifiers) : val else original_dig(key, *identifiers) end end end ``` This code also shows how I would define `Proc` argument behavior for arrays. The proc is called with each array item, and the *first* one for which a truthy value is evaluated is returned. ## Precedence I see this feature similar to [JSONPath's filter selector](https://www.rfc-editor.org/rfc/rfc9535.html#name-filter-selector), where the [equivalent path](https://jsonpath.com/#eJx1jlFrwjAQx79KOAQnlFKnPliQjTn2LHs1PsT2rIEs0eQ… for the introductory example would be: ``` $.batters.batter[?(@.type == 'Chocolate')].id ``` I am not familiar with similar implementations in other programming languages, so I cannot draw parallels there. ## Real-world examples Here's a [GitHub code search](https://github.com/search?q=%2F(%5Cw%5C%5B%5Cw%2B%3F%5C%5D%7C%5C.(f… with potential candidates that could be refactored with this new feature. There are some false positives on this link, sorry about that. The regex is also probably incomplete, so there could be more results. I will highlight two examples from the results and how they could be refactored: ```ruby # https://github.com/moraki-finance/ruby-experian/blob/84f7def9987b6377f4718a… value_section&.find { |d| d["Tipo"] == value_name }&.dig("ListaValores", "Valor")&.find { |v| v["Periodo"] == period.to_s }&.dig("Individual")&.to_i value_section&.dig(-> { it["Tipo"] == value_name }, "ListaValores", "Valor", -> { it["Periodo"] == period.to_s }, "Individual")&.to_i # https://github.com/cyfronet-fid/marketplace/blob/f84947777aa79d02fb98709241… datasource_data&.dig("identifiers", "alternativeIdentifiers")&.find { |id| id["type"] == "PID" }&.[]("value") datasource_data&.dig("identifiers", "alternativeIdentifiers", -> { it["type"] == "PID" }, "value") ``` ## Final thoughts The main benefit of this feature would be to not have to insert other methods in-between `#dig`, for example `#find` in the above examples. This could lead to cleaner code when handling complex data structures (such as returned from JSON APIs), with fewer usages of safe navigation. On the other hand, `Proc` argument could be misinterpreted by developers to mean something else (e.g. return _all_ items for which the proc returns a truthy value). `Proc` arguments could also be seen as non-idiomatic Ruby. It should also be clearly defined how many results such `dig`s return, just the first one for which the Proc is truthy (`#find` behavior), or all for which it's truthy (`#select` behavior). I admit at this point I'm not entirely sure, though I'm leaning towards the former (`#find`). Final note: in this feature request I considered only `Array#dig`, but `Hash#dig` could be considered as well (the proc receives each key/value pair). -- https://bugs.ruby-lang.org/

3 2

[ruby-core:121982] [Ruby Bug#21323] irb fails to start with Namespace
by Eregon (Benoit Daloze) 05 Jun '25

05 Jun '25

Issue #21323 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21323: irb fails to start with Namespace https://bugs.ruby-lang.org/issues/21323 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` $ irb irb(main):001> 6 * 7 => 42 $ RUBY_NAMESPACE=1 irb /home/eregon/prefix/ruby-master/bin/ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for know issues, etc. /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/did_you_mean/core_ext/name_error.rb:11: warning: irb is not part of the default gems since Ruby 3.5.0. Install irb from RubyGems. /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/did_you_mean/core_ext/name_error.rb:11: warning: irb is not part of the default gems since Ruby 3.5.0. Install irb from RubyGems. <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:141:in 'Kernel#require': cannot load such file -- irb (LoadError) Did you mean? erb from <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:141:in 'Kernel#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in 'Namespace::Loader#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in '<top (required)>' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Kernel#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Namespace::Loader#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in '<main>' <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require': cannot load such file -- irb (LoadError) Did you mean? erb from <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in 'Namespace::Loader#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in '<top (required)>' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Kernel#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Namespace::Loader#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in '<main>' zsh: exit 1 RUBY_NAMESPACE=1 irb ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:122355] [Ruby Feature#21389] Simplify Set#inspect output
by jeremyevans0 (Jeremy Evans) 05 Jun '25

05 Jun '25

Issue #21389 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #21389: Simplify Set#inspect output https://bugs.ruby-lang.org/issues/21389 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- As Set is now a core collection class, it should have special inspect output. Ideally, inspect output should be suitable to eval, similar to array and hash (assuming the elements are also suitable to eval): ```ruby set = Set[1, 2, 3] eval(set.inspect) == set # should be true ``` The simplest way to do this is to use the Set[] syntax: ```ruby Set[1, 2, 3].inspect # => "Set[1, 2, 3]" ``` I've submitted a pull request that implements this: https://github.com/ruby/ruby/pull/13488 The pull request deliberately does not use any subclass name in the output, similar to array and hash. I think it is more important that users know they are dealing with a set than which subclass: ```ruby Class.new(Set)[] # PR does: Set[] # not: #<Class:0x00000c21c78699e0>[] ``` However, it's easy to change the PR to use a subclass name if that is desired. -- https://bugs.ruby-lang.org/

3 2