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

[ruby-core:124530] [Ruby Feature#13683] Add strict Enumerable#single
by byroot (Jean Boussier) 14 Jan '26

14 Jan '26

Issue #13683 has been updated by byroot (Jean Boussier). > if AcriveSupport would define SoleItemExpectedEror = ArgumentError or something similar. We can do that, that's no problem. If `Enumerable#sole` lands in Ruby, I'll take care of handling any backward compatibility issue in Rails/Active Support. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116094 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124525] [Ruby Feature#13683] Add strict Enumerable#single
by matz (Yukihiro Matsumoto) 14 Jan '26

14 Jan '26

Issue #13683 has been updated by matz (Yukihiro Matsumoto). I now agree with having a method with proposed behavior. We have to pick a name for it. I don't like `single`. I have no strong opinion for/against `sole`. But I don't want to introduce a new exception class dedicated to this sole method (as `#sole` in ActiveSupport does). The other candidates are: - one! - only - lone - singular AI strongly suggested `only`. I am still wondering. Any opinion? One possible solution is providing our version of `sole` that raises `ArgumentError`, only if AcriveSupport would define `SoleItemExpectedEror = ArgumentError` or something similar. Matz. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116087 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124522] [Ruby Feature#21822] Expose Return Value in the ensure Block
by nobu (Nobuyoshi Nakada) 14 Jan '26

14 Jan '26

Issue #21822 has been updated by nobu (Nobuyoshi Nakada). Is the variable `nil` if an exception is raised, even for non-local variable? By analogy with `rescue`, it feels natural for me that the variable is unchanged in that case. ---------------------------------------- Feature #21822: Expose Return Value in the ensure Block https://bugs.ruby-lang.org/issues/21822#change-116082 * Author: artemb (Artem Borodkin) * Status: Open ---------------------------------------- I'd like to propose a simple feature that allows easy access to the return value inside an ensure block. ```ruby begin # ... ensure => ret # ret is nil if an exception is raised LOGGER.debug "return value: #{ret}" end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124520] [Ruby Feature#19107] Allow trailing comma in method signature
by k0kubun (Takashi Kokubun) 14 Jan '26

14 Jan '26

Issue #19107 has been updated by k0kubun (Takashi Kokubun). Can we reconsider this? To Matz' question (see also: [DevMeeting-2022-12-01](https://github.com/ruby/dev-meeting-log/blob/master/…) > Is there an actual case where this proposal is convenient? @byroot and I have shown real-world use cases in open-source repositories. In closed-source applications, e.g. at Shopify, it's common to see methods that have much more (optional, keyword) arguments, which would benefit from this syntax. At the Ruby Release 30th Party, in Koichi's presentation (which Matz missed), @byroot mentioned this feature as one of his wishes for the future of Ruby. IIRC, @shyouhei said this was rejected last time because this would cause a conflict in the syntax when parentheses are omitted. However, somebody else (I forgot, maybe @yui-knk or @nobu?) said some discrepancy between method definitions with parens and ones without parens already exist, and I'm sure we want this feature only when a method is defined with parens. So we shouldn't need to reject this for the previous reason. So, can we revisit this? Now that `it` is in, this is my most-wanted feature in Ruby now. I respect that there are people who don't put parens in method definitions (and therefore have no interest in this feature) or think trailing commas are awkward, but I'd like to remind you that there are other people who put parens in method definitions and want to minimize the git diff when a new parameter is added at the end of such method definitions with many parameters. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116080 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124516] [Ruby Feature#21821] Add Stack and SizedStack classes
by p8 (Petrik de Heus) 13 Jan '26

13 Jan '26

Issue #21821 has been updated by p8 (Petrik de Heus). Eregon (Benoit Daloze) wrote in #note-9: > It reminds me when I once tried to replace the queue in Puma's [thread pool](https://github.com/puma/puma/blob/main/lib/puma/thread_pool.rb) with a SizedQueue to remove the extra ConditionVariable & Mutex, but it's not possible, it does things that SizedQueue can't do. The ConditionVariable in Puma 7's thread pool is causing issues in JRuby: https://github.com/jruby/jruby/issues/9140 Sequel's [timed_queue](https://github.com/jeremyevans/sequel/blob/4293be3cb8dbb50992e… avoids the ConditionalVariable with [big improvements for some](https://github.com/jeremyevans/sequel/discussions/2207), but I'm not sure that can be applied to Puma. ---------------------------------------- Feature #21821: Add Stack and SizedStack classes https://bugs.ruby-lang.org/issues/21821#change-116076 * Author: byroot (Jean Boussier) * Status: Open * Target version: 4.1 ---------------------------------------- ### Context `Queue` and `SizedQueue` are very useful and performant constructs, however they only allow for FIFO queues. Some use cases do call for LIFO queues AKA stacks. For instance, in the case of connection pool, it's often preferable to use a stack. ### Feature I'd like to introduce `Stack` and `SizedStack` classes, to mirror `Queue` and `SizedQueue`. They'd have exactly the same method and behavior at the exception of dequeuing order. ### Thread namespace? Currently `Queue` and `SizedQueue` are technically defined under `Thread` and aliased in `Object`. I wonder if that's something we should do for `Stack` too, or just some historical thing we shouldn't perpetuate. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124288] [Ruby Bug#21790] `Socket.getaddrinfo` hangs after `fork()` on macOS 26.1 (Tahoe) for IPv4-only hosts
by adamoffat (Adam Moffat) 13 Jan '26

13 Jan '26

Issue #21790 has been reported by adamoffat (Adam Moffat). ---------------------------------------- Bug #21790: `Socket.getaddrinfo` hangs after `fork()` on macOS 26.1 (Tahoe) for IPv4-only hosts https://bugs.ruby-lang.org/issues/21790 * Author: adamoffat (Adam Moffat) * Status: Open * ruby -v: 3.3.8 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ruby's `Socket.getaddrinfo` hangs indefinitely in forked child processes on macOS 26.1 (Tahoe) when resolving IPv4-only hostnames. This is a regression that does not occur on macOS 15.x (Sonoma) or earlier. **Ruby version:** ruby 3.3.8 (2025-04-09 revision b200bad6cd) [arm64-darwin24] Also confirmed this affects Ruby 3.2.6 and 3.4.1. **Reproducible script:** ``` ruby require "socket" require "timeout" puts "Ruby #{RUBY_VERSION} on #{RUBY_PLATFORM}" Socket.getaddrinfo("api.segment.io", 443, nil, :STREAM) puts "Parent: DNS completed" pid = fork do puts "Child: Attempting DNS resolution..." begin Timeout.timeout(90) do Socket.getaddrinfo("api.segment.io", 443, nil, :STREAM) end puts "Child: SUCCESS" exit 0 rescue Timeout::Error puts "Child: FAILED - hung for 90 seconds" exit 1 end end Process.wait(pid) ``` **Note:** Remove the `Timeout.timeout(90)` wrapper to observe the hang indefinitely. The timeout is included only to allow the script to exit for testing purposes. **Result of reproduce process:** ``` Ruby 3.3.8 on arm64-darwin24 Parent: DNS completed Child: Attempting DNS resolution... Child: FAILED - hung for 90 seconds ``` The child process hangs with one thread consuming 100% CPU. Expected result: The child process should complete DNS resolution successfully, as it does on macOS 15.x and earlier. **Analysis:** Stack trace shows: Main thread: Blocked in `wait_getaddrinfo` → `_pthread_cond_wait` DNS thread: Spinning in `_gai_nat64_second_pass` → `nw_path_access_agent_cache` → `_os_log_preferences_refresh` → `SIGSEGV` The crash occurs in macOS's NAT64 synthesis code path. Ruby's signal handler catches the `SIGSEGV` but cannot recover, causing the DNS thread to spin. **Key observations:** - Only affects IPv4-only hosts. Hosts with IPv6 (like google.com) work correctly. - Using `AF_INET` instead of `AF_UNSPEC` works. `Socket.getaddrinfo("api.segment.io", 443, Socket::AF_INET, :STREAM)` succeeds. - Python is not affected. Python calls `getaddrinfo()` synchronously without a background thread. - Parent must do DNS before fork. If the parent has not called getaddrinfo(), the child works correctly. **Workaround:** - Use `resolv-replace` to bypass the native DNS resolver: `require "resolv-replace"` **Impact:** This breaks all Ruby applications using pre-forking worker models (Resque, Unicorn, Puma, Sidekiq, Passenger) on macOS Tahoe. **Apple Bug Report:** Filed with Apple as Feedback Assistant #FB21364061 ---Files-------------------------------- stack_trace.txt (66.6 KB) ruby_dns_fork_bug.rb (1.02 KB) -- https://bugs.ruby-lang.org/

2 8

[ruby-core:124513] [Ruby Feature#21821] Add Stack and SizedStack classes
by byroot (Jean Boussier) 13 Jan '26

13 Jan '26

Issue #21821 has been updated by byroot (Jean Boussier). > IOW, I think we should have performance numbers here and implemented use cases that pass the relevant test suites Yes that's fair. I meant to re-implement the `redis-client` pool using `Thread::Queue` as a proof of concept, but didn't get around to it yet. ---------------------------------------- Feature #21821: Add Stack and SizedStack classes https://bugs.ruby-lang.org/issues/21821#change-116073 * Author: byroot (Jean Boussier) * Status: Open * Target version: 4.1 ---------------------------------------- ### Context `Queue` and `SizedQueue` are very useful and performant constructs, however they only allow for FIFO queues. Some use cases do call for LIFO queues AKA stacks. For instance, in the case of connection pool, it's often preferable to use a stack. ### Feature I'd like to introduce `Stack` and `SizedStack` classes, to mirror `Queue` and `SizedQueue`. They'd have exactly the same method and behavior at the exception of dequeuing order. ### Thread namespace? Currently `Queue` and `SizedQueue` are technically defined under `Thread` and aliased in `Object`. I wonder if that's something we should do for `Stack` too, or just some historical thing we shouldn't perpetuate. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124512] [Ruby Feature#21821] Add Stack and SizedStack classes
by Eregon (Benoit Daloze) 13 Jan '26

13 Jan '26

Issue #21821 has been updated by Eregon (Benoit Daloze). byroot (Jean Boussier) wrote in #note-8: > About the second one, it's clever but not sure if ideal because it's no longer "atomic" on MRI, so is subject to `Thread#raise`. Looking at the `connection_pool` gem, one thing that slows it down considerably is the numerous calls to `Thread.handle_interrupt` to avoid leaking connections when `Timeout` is used. I see https://github.com/mperham/connection_pool/blob/f3645821d02fe8de5089f31b616… There is lots of code in checkin/checkout anyway, those `Thread.handle_interrupt` can't be removed even if SizedStack exists. Even if it's a single method call directly to a SizedStack method, that could still check interrupts, and it definitely would for `pop`, so you'd still need the `Thread.handle_interrupt`. On that topic maybe we should have all `ensure` automatically be `Thread.handle_interrupt(Object => :never)` (https://bugs.ruby-lang.org/issues/17849#note-5) or a way to opt-in per `ensure`. Also [ConnectionPool::TimedStack](https://github.com/mperham/connection_pool/blob… has a bunch of code which doesn't seem to me like it could be replaced or implemented with a SizedStack (but I haven't tried). It reminds me when I once tried to replace the queue in Puma's [thread pool](https://github.com/puma/puma/blob/main/lib/puma/thread_pool.rb) with a SizedQueue to remove the extra ConditionVariable & Mutex, but it's not possible, it does things that SizedQueue can't do. IOW, I think we should have performance numbers here and implemented use cases that pass the relevant test suites, otherwise we might add a class that actually can't be used for the intended use cases. ---------------------------------------- Feature #21821: Add Stack and SizedStack classes https://bugs.ruby-lang.org/issues/21821#change-116072 * Author: byroot (Jean Boussier) * Status: Open * Target version: 4.1 ---------------------------------------- ### Context `Queue` and `SizedQueue` are very useful and performant constructs, however they only allow for FIFO queues. Some use cases do call for LIFO queues AKA stacks. For instance, in the case of connection pool, it's often preferable to use a stack. ### Feature I'd like to introduce `Stack` and `SizedStack` classes, to mirror `Queue` and `SizedQueue`. They'd have exactly the same method and behavior at the exception of dequeuing order. ### Thread namespace? Currently `Queue` and `SizedQueue` are technically defined under `Thread` and aliased in `Object`. I wonder if that's something we should do for `Stack` too, or just some historical thing we shouldn't perpetuate. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124511] [Ruby Feature#21821] Add Stack and SizedStack classes
by byroot (Jean Boussier) 13 Jan '26

13 Jan '26

Issue #21821 has been updated by byroot (Jean Boussier). > there are 2 reasonable alternatives About the second one, it's clever but not sure if ideal because it's no longer "atomic" on MRI, so is subject to `Thread#raise`. Looking at the `connection_pool` gem, one thing that slows it down considerably is the numerous calls to `Thread.handle_interrupt` to avoid leaking connections when `Timeout` is used. ---------------------------------------- Feature #21821: Add Stack and SizedStack classes https://bugs.ruby-lang.org/issues/21821#change-116071 * Author: byroot (Jean Boussier) * Status: Open * Target version: 4.1 ---------------------------------------- ### Context `Queue` and `SizedQueue` are very useful and performant constructs, however they only allow for FIFO queues. Some use cases do call for LIFO queues AKA stacks. For instance, in the case of connection pool, it's often preferable to use a stack. ### Feature I'd like to introduce `Stack` and `SizedStack` classes, to mirror `Queue` and `SizedQueue`. They'd have exactly the same method and behavior at the exception of dequeuing order. ### Thread namespace? Currently `Queue` and `SizedQueue` are technically defined under `Thread` and aliased in `Object`. I wonder if that's something we should do for `Stack` too, or just some historical thing we shouldn't perpetuate. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123878] [Ruby Bug#21702] `UNIXSocket` on Windows: suprising results in `#recvfrom` and `#remote_address`
by trinistr (Alexander Bulancov) 13 Jan '26

13 Jan '26

Issue #21702 has been reported by trinistr (Alexander Bulancov). ---------------------------------------- Bug #21702: `UNIXSocket` on Windows: suprising results in `#recvfrom` and `#remote_address` https://bugs.ruby-lang.org/issues/21702 * Author: trinistr (Alexander Bulancov) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Support for `UNIXSocket` on Windows was added in #19135. Through testing in ruby/spec, I identified unexpected results in two methods: 1. `#remote_address.to_s` always returns 110 bytes, compared to `#local_address.to_s` which returns only needed bytes. Example: ```ruby # test (@addr is remote_address, @b is the socket created with UNIXServer#accept): @addr.to_s.should == @b.local_address.to_s # failure: "\x01\x00D:/a/spec/spec/rubyspec_temp/2032_3/unix.sock\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" == "\x01\x00D:/a/spec/spec/rubyspec_temp/2032_3/unix.sock\x00" ``` Note how the address is correct, and `#unix_path`s are indeed equal, but there are NUL bytes filling the string representation up to 110 bytes. This number does not depend on the length of path name. 2. Much more worryingly, `UNIXSocket#recvfrom` **dumps 2047 bytes of memory** as the remote address: ```ruby # test: @server.recvfrom(5).should == ['hello', ['AF_UNIX', '']] # failure: ["hello",["AF_UNIX","\x14\xB3v\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x01\x00\x00\x00\x00\x00\x00\xAB\xCD\x12C\xFF\x7F<snip>"]] == ["hello", ["AF_UNIX", ""]] ``` This seems to be a result of `union_sockaddr` having a `char place_holder[2048]` member inside, though it isn't clear why is this used instead of `sockaddr_un` member. These results are obtained from GitHub runners, as I don't have a machine to test directly. This is the PR in ruby/spec which brought this up: https://github.com/ruby/spec/pull/1300. -- https://bugs.ruby-lang.org/

3 4