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

[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

[ruby-core:125977] [Ruby Bug#22187] High major GCs caused by specific concurrent workloads in 3.4
by rpeng (Richard Peng) 11 Jul '26

11 Jul '26

Issue #22187 has been reported by rpeng (Richard Peng). ---------------------------------------- Bug #22187: High major GCs caused by specific concurrent workloads in 3.4 https://bugs.ruby-lang.org/issues/22187 * Author: rpeng (Richard Peng) * Status: Open * ruby -v: 3.4.10 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, We are running into an issue that's very similar to https://bugs.ruby-lang.org/issues/21838, and believe it has the same root cause of global allocatable slots by running thru git-bisect (https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/07…) For very specific workloads (high concurrency, large-ish file downloads), we are seeing that the amount of major GCs has markedly increased under 3.4. It has occurred in our production workloads and lead to increased tail latencies (almost doubling our p75 / p99s). To reproduce: 1. Save the reproduction script below to a ruby file repro.rb 2. Run it against official ruby images (3.3.11-trixie, and 3.4.10-trixie) 3. See the differences in major GC count ``` docker run --rm --pull always -v "$PWD/repro.rb:/repro.rb:ro" ruby:3.3.11-trixie ruby /repro.rb # output: [3.3.11] threads=9 total=2000 body=4MB majors=8 minors=771 docker run --rm --pull always -v "$PWD/repro.rb:/repro.rb:ro" ruby:3.4.10-trixie ruby /repro.rb # output: [3.4.10] threads=9 total=2000 body=4MB majors=56 minors=752 ``` Reproduction script: ``` ruby # repro.rb require "socket" require "net/http" THREADS = 9 ITERATIONS = 2000 ITERATIONS_PER_THREAD = ITERATIONS / THREADS BODY_MB = 4 BODY = 'x' * (BODY_MB * 1024 * 1024) srv = TCPServer.new("127.0.0.1", 0) PORT = srv.addr[1] Thread.new do loop do begin conn = srv.accept rescue StandardError break end Thread.new(conn) do |c| begin loop do received_line = false while (line = c.gets) received_line = true break if line == "\r\n" end break unless received_line c.write "HTTP/1.1 200 OK\r\nContent-Length: #{BODY.bytesize}\r\n" \ "Connection: keep-alive\r\n\r\n" c.write BODY end ensure c.close end end end end def download Net::HTTP.get("127.0.0.1", "/", PORT).bytesize end # warm up the heap to steady state, then measure only the download loop. 2.times { Array.new(THREADS) { Thread.new { 2.times { download } } }.each(&:join) } Process.warmup before = GC.stat Array.new(THREADS) { Thread.new { ITERATIONS_PER_THREAD.times { download } } }.each(&:join) after = GC.stat puts format("[%s] threads=%d total=%d body=%dMB majors=%d minors=%d", RUBY_VERSION, THREADS, ITERATIONS, BODY_MB, after[:major_gc_count] - before[:major_gc_count], after[:minor_gc_count] - before[:minor_gc_count]) srv.close ``` We _suspect_ that this line change here: https://github.com/ruby/ruby/pull/11562/changes#diff-d23f31a61dfe958dc75396… is causing more aggressive major GCs when the heap should be growing instead, but I am admittedly not well versed in Ruby core code. We made an experiment to add back the check (total_slots < init_slots) in gc/default.c, and it seemed to have remediated the issue, but I'm not sure what trade offs comes with that change. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:116083] [Ruby master Feature#20163] Introduce #bit_count method on Integer
by garrison (Garrison Jensen) 10 Jul '26

10 Jul '26

Issue #20163 has been reported by garrison (Garrison Jensen). ---------------------------------------- Feature #20163: Introduce #bit_count method on Integer https://bugs.ruby-lang.org/issues/20163 * Author: garrison (Garrison Jensen) * Status: Open * Priority: Normal ---------------------------------------- This feature request is to implement a method called #bit_count on Integer that returns the number of ones in the binary representation of the absolute value of the integer. ``` n = 19 n.bit_count #=> 3 (-n).bit_count #=> 3 ``` This is often useful when you use an integer as a bitmask and want to count how many bits are set. This would be equivalent to ``` n.to_s(2).count("1") ``` However, this can be outperformed by ``` def bit_count(n) count = 0 while n > 0 n &= n - 1 # Flip the least significant 1 bit to 0 count += 1 end count end ``` I think this would be a useful addition because it would fit alongside the other bit-related methods defined on integer: `#bit_length,` `#allbits?`, `#anybits?`, `#nobits?`. Also, when working with bitmasks, a minor upgrade to performance often results in a significant improvement. Similar methods from other languages: https://docs.python.org/3/library/stdtypes.html#int.bit_count https://doc.rust-lang.org/std/primitive.i32.html#method.count_ones -- https://bugs.ruby-lang.org/

14 32