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

[ruby-core:126055] [Ruby Feature#15222] Add a way to distinguish between Struct classes with and without keyword initializer
by Earlopain (Earlopain _) 11 Jul '26

11 Jul '26

Issue #15222 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed Added a while ago via https://bugs.ruby-lang.org/issues/18008 ---------------------------------------- Feature #15222: Add a way to distinguish between Struct classes with and without keyword initializer https://bugs.ruby-lang.org/issues/15222#change-118053 * Author: pluff (Pavel Shutsin) * Status: Closed ---------------------------------------- With Ruby 2.5.0 Struct subclasses can have different `initialize` arguments list based on `keyword_init` option. However, there is no way in Ruby to distinguish Structs with keyword arguments syntax and without. I propose a class method `keyword_init?` that will allow developers to understand if given structure has keyword based initializer or not. Example use case for serialization: ``` Foo = Struct.new(:foo, keyword_init: true) Bar = Struct.new(:bar) def dump_and_load_struct(object) serialized = object.to_h object.class.new(object.class.keyword_init? ? serialized : serialized.values) end dump_and_load_struct(Foo.new(foo: 1)) # #<struct Foo foo=1> dump_and_load_struct(Bar.new(2)) # #<struct Bar bar=1> ``` An issue that might be related: https://bugs.ruby-lang.org/issues/14314 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126054] [Ruby Feature#10949] Time is WB unprotected
by Earlopain (Earlopain _) 11 Jul '26

11 Jul '26

Issue #10949 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed It's WB protected since https://github.com/ruby/ruby/commit/1c0127ed5e1aaf1386e2176e499d4cb25d171a21 ---------------------------------------- Feature #10949: Time is WB unprotected https://bugs.ruby-lang.org/issues/10949#change-118050 * Author: sylvain.joyeux (Sylvain Joyeux) * Status: Closed ---------------------------------------- Ruby's built-in Time object is shady. Unfortunately, it is an object that can commonly be created in big numbers (think logs or stuff like that), and since they don't store relationship with other objects they are perfect candidate for the oldgen. I don't really know if there is a kind of policy about which built-in Ruby objects should be sunny or not, so I just put this as a feature request (as opposed to having it as a bug) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126053] [Ruby Feature#15724] Optionally suppress output from IRB for assignment expressions
by Earlopain (Earlopain _) 11 Jul '26

11 Jul '26

Issue #15724 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed The irb PR is merged, presumably this is done ---------------------------------------- Feature #15724: Optionally suppress output from IRB for assignment expressions https://bugs.ruby-lang.org/issues/15724#change-118049 * Author: onlynone (Steven Willis) * Status: Closed ---------------------------------------- Most REPLs I've used don't print out the output of assignment expressions like `a = 1`. Being able to suppress this output is very useful when you have a string which is essentially a blob, an object with a large string representation, or even an array of several objects like this. This happens to me often with rails' ActiveRecords where a query might return hundreds of objects that I just want to assign to a variable and don't want to inspect yet. It's even worse with rails because queries are run lazily, just because I did `a = User.where(name='Sally')` doesn't mean I actually wanted to execute that query against the db yet. I might want to do `a = a.where('age > 35')`. But irb doing the echo forces the evaluation. I wrote this patch to irb: https://github.com/ruby/irb/pull/12 which would suppress irb's echo for assignment expressions when a new config setting: `context.echo_on_assignment` is false. It uses the new `RubyVM::AbstractSyntaxTree` to determine whether an expression is an assignment expression, so it only works on ruby >= 2.6.0. I'd very much welcome some feedback and any ideas on how to get it to work for earlier ruby versions. I had also written a first-pass proof-of-concept that used the `parser` gem and would work for ruby >= 2.0.0 (https://github.com/ruby/irb/pull/11) This version obviously can't be merged because of the external dependency, but perhaps it can be treated like readline: use it if it's already installed, but don't depend on it? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126052] [Ruby Feature#14624] #{nil} allocates a fresh empty string each time
by Earlopain (Earlopain _) 11 Jul '26

11 Jul '26

Issue #14624 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed `nil.to_s` is frozen and returns the same instance since ruby 2.7 ---------------------------------------- Feature #14624: #{nil} allocates a fresh empty string each time https://bugs.ruby-lang.org/issues/14624#change-118048 * Author: bumblingbear (Dillon Welch) * Status: Closed ---------------------------------------- This causes a bunch of unnecessary string allocations in the following scenario: `"#{'rails' unless boolean_condition} is great"`. Each time this line is called when `boolean_condition` is true, it evaluates to `nil` and when `nil` is interpolated into a string it allocates an empty string. Ideally, the behavior of `nil.to_s` would reference a frozen empty string that wouldn't need to be reallocated each time. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126051] [Ruby Feature#14606] Change begin-else-end without rescue from warning to syntax error
by Earlopain (Earlopain _) 11 Jul '26

11 Jul '26

Issue #14606 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed Both are syntax errors now, the first example since https://github.com/ruby/ruby/commit/140512d2225e6fd046ba1bdbcd1a27450f55c233 ---------------------------------------- Feature #14606: Change begin-else-end without rescue from warning to syntax error https://bugs.ruby-lang.org/issues/14606#change-118047 * Author: joker1007 (Tomohiro Hashidate) * Status: Closed ---------------------------------------- ~~~ ruby begin p :foo else p :bar end # => :foo # => :bar ~~~ ~~~ ruby [1,2,3].each do p :foo else p :bar end # => :foo # => :bar ~~~ begin-else-end without rescue is useless and dangerous. (especially, do-else-end is easy to mistake) In actually, programmer never intend to write like these. Ruby interpreter can guard this case by syntax error. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126050] [Ruby Feature#12969] Allow optional parameter in String#strip and related
by Earlopain (Earlopain _) 11 Jul '26

11 Jul '26

Issue #12969 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed https://bugs.ruby-lang.org/issues/21552 implemented this ---------------------------------------- Feature #12969: Allow optional parameter in String#strip and related https://bugs.ruby-lang.org/issues/12969#change-118046 * Author: herwinw (Herwin Quarantainenet) * Status: Closed ---------------------------------------- `String#strip` and related methods have a hardcoded match on whitespace, defined as "null, horizontal tab, line feed, vertical tab, form feed, carriage return, space". It would be nice to allow a parameter to specify the characters you want to strip. This would result in a kind of marriage between `String#delete` and `String#chomp`. The first one is an example on how to specify character classes, the second one is an example on how to pass an optional parameter. Examples how this would work: ```ruby "hellooo ".rstrip #=> "hellooo" "hellooo ".rstrip(" ") #=> "hellooo" "hellooo ".rstrip(" o") #=> "hell" "hellooo ".rstrip("o ") #=> "hell" "hellooo ".rstrip("o") #=> "hellooo " "hellooo ".chomp(" ") #=> "hellooo ", only replaces one character, thus not a sensible alternative ``` The same behaviour can be achieved by using `String#sub` and the correct anchors, but I think an optional parameter to `String#strip` is cleaner to read. It's probably faster too, since we don't have to initialize a regex state machine. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125650] [Ruby Feature#22097] Add Proc#with_refinements
by shugo (Shugo Maeda) 11 Jul '26

11 Jul '26

Issue #22097 has been reported by shugo (Shugo Maeda). ---------------------------------------- Feature #22097: Add Proc#with_refinements https://bugs.ruby-lang.org/issues/22097 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- ## Abstract I propose `Proc#with_refinements` to support block-level refinements. ```ruby module StringExt refine String do def shout = upcase + "!" end end original = ->(s) { s.shout } refined = original.with_refinements(StringExt) p refined.call("hello") # "HELLO!" p original.call("hello") # NoMethodError ``` ## Background and Motivation I previously proposed `Proc#using` in [Feature #16461], but it introduced semantic complexities because it mutated existing blocks. Instead of mutating the existing block, `Proc#with_refinements` returns a new `Proc` object with its own isolated call sites. This approach makes its semantics much simpler than `Proc#using`, and it avoids thread-safety issues and plays nicely with inline caches. ## Limitation Similar to `Proc#binding`, `Proc#with_refinements` raises ArgumentError if the receiver is not created from a Ruby block. ```ruby :to_s.to_proc.with_refinements(StringExt) #=> ArgumentError ``` ## Implementation I've opened a pull request: https://github.com/ruby/ruby/pull/17248 A PoC for JRuby is also available at: https://github.com/shugo/jruby/pull/2 ### Data structure changes * Added a bit field `has_refinements` to `rb_proc_t`. * Added a hidden instance variable to `Proc` to store a `cref` with the applied refinements. * Added a single-entry cache `refinement_memo` to `rb_iseq_constant_body`. ### Deep copy of iseq and caching `Proc#with_refinements` performs a deep copy of the receiver's `iseq` to isolate its call sites from the original `Proc`. While a deep copy can be an expensive operation, the single-entry cache in `rb_iseq_constant_body` mitigates this overhead effectively for most practical use cases where the same refinements are applied repeatedly. ### Overhead for code not using Proc#with_refinements * Memory footprint: Neither internal structure grows in size. `has_refinements` is a 1-bit field added to rb_proc_t's existing bit field, and `refinement_memo` shares a union with `mandatory_only_iseq` in rb_iseq_constant_body. * Execution speed: The common `Proc#call` path is kept frameless and only adds a single `has_refinements` bit check. * GC: The mark/free/memsize functions add a single branch per `iseq` to select the union member. Benchmark results: https://gist.github.com/shugo/ddfe92f28ea31e6527a2f270e6daee7c Here's an excerpt from the results, where `compare-ruby` is master and `built-ruby` is the branch for this feature (focusing on Proc/Block operations): | |compare-ruby|built-ruby| |:------------------------------------|-----------:|---------:| |vm_proc | 47.215M| 46.149M| | | 1.02x| -| |vm_yield | 1.649| 1.754| | | -| 1.06x| -- https://bugs.ruby-lang.org/

4 11

[ruby-core:126047] [Ruby Feature#9779] Add Module#descendants
by shugo (Shugo Maeda) 11 Jul '26

11 Jul '26

Issue #9779 has been updated by shugo (Shugo Maeda). Subject changed from Add Module#descendents to Add Module#descendants It seems that there's no progress since `Class#descendants` ([Feature #14394]) was reverted, so I've created a new pull request: https://github.com/ruby/ruby/pull/17807 I prefer `Module#descendants` because `Class` would automatically inherit `Module#descendants` but the converse does not hold. I also believe `Module#descendants` is a more natural API than `Class#descendants`, because `descendants` should ideally be the dual of `Module#ancestors`; i.e., `y ∈ x.descendants ⟺ x ∈ y.ancestors`. Defining it at the `Module` level also answers the design question left open when [Feature #14394] was reverted (https://bugs.ruby-lang.org/issues/14394#note-33) Assuming that `Module#descendants` is the dual of `Module#ancestors`, it should include `self` in its return value. However, I implemented `Module#descendants` not to include `self`, following ActiveSupport's `Class#descendants` and the reverted implementation of [Feature #14394]. Singleton classes are not included either, following the documented behavior of `Class#subclasses`. Note that `[mod, *mod.descendants]` can be used when `self` is needed. The implementation reuses the existing subclass lists maintained for method cache invalidation, so no additional bookkeeping is introduced. Like `Class#subclasses`, the receiver does not hold strong references to its descendants, so the result may change after GC. Refinements are not included. One use case of `Module#descendants` is Aspect Oriented Programming (illustrative, not a working example): ```ruby module Aspect def self.around(type, method_pattern, &advice) type.descendants.grep(Class).each do |klass| methods = klass.instance_methods(false).grep(method_pattern) next if methods.empty? wrapper = Module.new do methods.each do |name| define_method(name) do |*args, &blk| advice.call(self, name, args) { super(*args, &blk) } end end end klass.prepend(wrapper) end end end Aspect.around(Persistable, /\Asave/) do |obj, name, args, &proceed| logger.info("#{obj.class}##{name} start") proceed.call ensure logger.info("#{obj.class}##{name} end") end ``` A similar approach could also be used by instrumentation libraries such as OpenTelemetry and Datadog's dd-trace-rb. Note that we have to use hooks like `inherited` or `included` to patch classes which will be loaded later. `Module#descendants` is also useful for diagnostics, e.g., finding all classes a monkey patch is prepended to, or all models that include a specific Rails concern. ---------------------------------------- Feature #9779: Add Module#descendants https://bugs.ruby-lang.org/issues/9779#change-118040 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- Now classes have links to their subclasses, so how about to add Module#descendents? ```ruby class X end class Y < X end class Z < Y end p X.descendents #=> [X, Y, Z] module A end module B include A end module C include A end p A.descendents #=> [A, C, B] ``` One of my own use cases is to implement AspectJ like pointcut which matches all subclasses of the given class. Considerations: * Should the return value of Module#descendents include self? * Should the return value of Module#descendents include singleton classes? I attach a patch, where the return value includes both self and singleton classes. ---Files-------------------------------- 0001-Add-Module-descendents.patch (3.75 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126046] [Ruby Feature#14394] Class.descendants
by shugo (Shugo Maeda) 11 Jul '26

11 Jul '26

Issue #14394 has been updated by shugo (Shugo Maeda). Status changed from Closed to Assigned It's accidentally closed by the above commit. Sorry. ---------------------------------------- Feature #14394: Class.descendants https://bugs.ruby-lang.org/issues/14394#change-118039 * Author: ridiculous (Ryan Buckley) * Status: Assigned * Assignee: ko1 (Koichi Sasada) ---------------------------------------- There have been numerous implementations of the method Class.descendants by various gems. However, I can't help but think that this ability should be included in the Ruby language itself. Especially since Ruby already offers the counterpart method Class.ancestors. Would it possible to add a `descendants` class method? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125754] [Ruby Bug#22111] Non-symbolic hash keys with `expr : value` syntax
by yertto (_ yertto) 11 Jul '26

11 Jul '26

Issue #22111 has been reported by yertto (_ yertto). ---------------------------------------- Bug #22111: Non-symbolic hash keys with `expr : value` syntax https://bugs.ruby-lang.org/issues/22111 * Author: yertto (_ yertto) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- # Non-symbolic hash keys with `expr : value` syntax Allow `expr : value` as a computed hash key. Almost 20 years in the making, the missing puzzle piece for Hash's "new" colon syntax: ```ruby h = { name: "symbol shorthand", # Ruby 1.9+ "quoted label": "symbol label", # Ruby 2.2+ (Feature #4935) value_omission: , # Ruby 3.1+ (Feature #14579) expr : "non symbol", # THIS PROPOSAL } ``` ## Motivation Ruby has several colon-based hash key syntaxes for symbolic keys, but the `=>` ("hash rocket") is still needed for non-symbolic keys. Adding `expr : value` is a backwards compatible leap forward toward allowing all-colon hashes for all key types: ```ruby ## Before -- mixed styles n = 42; { name: "Alice", role: "admin", "key-#{n}": "foo", RUBY_VERSION:, n => "bar" }.keys # => [:name, :role, :"key-42", :RUBY_VERSION, 42] ## After -- uniform colon syntax n = 42; { name: "Alice", role: "admin", "key-#{n}": "foo", RUBY_VERSION:, n : "bar" }.keys # => [:name, :role, :"key-42", :RUBY_VERSION, 42] ``` Could this be what we need to one day retire our old friend "hash rocket" from Hashes entirely? ### Completing the colon family | Example | Ruby | Feature | Key type | |---------|------|---------|----------| | `{ name: value }` | v1.9 | | Symbol | | `{ "quoted label": value }` | v2.2 | Feature #4935 | Symbol (quoted label) | | `{ value_omission: }` | v3.1 | Feature #14579 | Value omission | | `{ expr : value }` | *???* | **Feature #XXXXX** | Non-symbolic | ### Readability for computed-key-heavy code Code that builds dynamic hashes currently forces a style break midway through a literal. This is especially noticeable with computed keys, numeric keys, or variable-driven keys. ### Reducing `=>` overloading The `=>` token is now being used to serve more purposes than just the Hash literal (aka "Hash rocket") it was originally used for. - rightward assignment ``` expr => var ``` - pattern capture ``` case {name: "Alice", role: "admin"} in {name: String => name, role:} # capture the name String value into `name` p name # => "Alice" end ``` - rescue variables ``` rescue SomeExceptionClass => e ``` ``` rescue => e ``` Reducing the rocket's use in Hashes simplifies the language, especially for newcomers. ## Design ### Disambiguation A label-eligible expression (bareword identifier or quoted string) followed by `:` with **no space** is a symbol key. The same expression followed by `:` with **a space** cannot be a label, so it becomes a computed key: ```ruby { a: 1 } # => {:a=>1} symbol key, label syntax { a : 1 } # => {1=>1} variable `a`, expr-colon (space disambiguates) ``` Expressions that cannot be labels never need a space, so there is no ambiguity to resolve: ```ruby { "a": 1 } # => {:a=>1} symbol key { "a" : 1 } # => {"a"=>1} string "a" { 42: 1 } # => {42=>1} integer 42 { Math::Pi: 1 } # => {3.141592653589793 => 1} ``` Other expressions also work without a space — there is no ambiguity to resolve: ```ruby { foo(): 1 } # computed, method call result { -42: 1 } # computed, negative integer { 1 ? 10 : 20: 1 } # computed, ternary expression result (1 is truthy) ``` ## Relationship to Feature #22108 The earlier proposal [Feature #22108](https://bugs.ruby-lang.org/issues/22108) suggested `{ (expr): value }` using parenthesized expressions with a lexer-generated label token (`tLABEL_END`). I assumed there'd be too many dragons to fight with whitespace sensitivity. However, after making the code changes somehow it just worked for all the test cases I threw at it. ¯\_(ツ)_/¯ | | `(expr): value` | `expr : value` | |---|---|---| | Parser changes | Lexer + grammar | Grammar only | | New fields | `hash_nest` | None | | LALR conflicts | 0 | 0 | | Parens required? | Yes | No | | Interpolated key | `("key-#{n}"): val` | `"key-#{n}" : val` | | Integer key | `(42): val` | `42: val` | The whitespace version is strictly more general, has a simpler implementation, and requires no lexer changes. ## Edge cases ```ruby { a: 1 } # => {:a=>1} symbol key (unchanged) { a : 1 } # => {42=>1} computed key { 42: 1 } # => {42=>1} computed key { -42: 1 } # => {-42=>1} computed key { "a" : 1 } # => {"a"=>1} computed key {%"a": 1} # => {"a"=>1} percent string as computed key { (1+2): "three" } # => {3=>"three"} parenthesized expression { n : n } # => {42=>42} expression as both key and value { n : } # syntax error value omission not supported { n : 1, } # => {42=>1} trailing comma ok { 1 ? 10 : 20: 1 } # => {10=>1} ternary inner, colon outer (1 is truthy) ``` ## Implementation Two files (plus tests): - **`parse.y`**: One new production in `assoc`: `| arg_value ':' arg_value` - **`prism/prism.c`**: In `parse_assocs`, accept `PM_TOKEN_COLON` when `pm_symbol_node_label_p` returns false Zero lexer changes, zero new fields, zero LALR conflicts. PR: [#17318](https://github.com/ruby/ruby/pull/17318) ## Historical context A version of this was discussed on ruby-core in October 2007 (as part of ["General hash keys for colon notation"](https://public-inbox.org/ruby-core/E1ImQBE-00033s-IZ@x31/T/), murphy). Unfortunately it was brought up during the v1.9 feature freeze, but it looks like [Matz's invitation to discuss for v2.0](https://public-inbox.org/ruby-core/E1ImQA8-00033T-8c@x31/) didn't end up going anywhere. Since then, `"quoted label":` (Ruby 2.2, Feature #4935) and value omission (Ruby 3.1, Feature #14579) have expanded the colon family, making the computed-key gap more conspicuous. This proposal fills that gap with a minimal grammar change that requires no new lexer states. ## Open questions - Should `{ a : }` be a value omission? (Would need compile-time inference.) - Is there community appetite for eventually deprecating `=>` from hash literals? ## Future directions All colon-based key syntaxes would now be available. This opens up the possibility of eventually deprecating `=>` from Hash literals (while keeping it for rescue, pattern matching, and rightward assignment). This proposal does not require that change — it is simply the enabling step, and any deprecation timeline could be a separate discussion. -- https://bugs.ruby-lang.org/

6 10