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

[ruby-core:124591] Invitation to RubyKaigi 2026
by Akira Matsuda 19 Jan '26

19 Jan '26

To: ruby-core committers We’re happy to announce that registration for RubyKaigi 2026 is now open! As is tradition, all Ruby core team members (with direct commit access to the Git repository) are invited to attend the conference free of charge. Please register via the following ticketing URL: https://ti.to/rubykaigi/2026/with/8jz7nne4osc For the “Committer account name” field, please enter the account name listed in the Ruby committer email list on GitHub: https://github.com/ruby/ruby-commit-hook/blob/master/config/email.yml Alternatively, you may use your Redmine account name, SVN account name, or any equivalent identifier that clearly identifies you as a Ruby core committer. See you in Hakodate! 🌟 -- Akira Matsuda / RubyKaigi 2026 team

1 0

[ruby-core:124571] [Ruby Bug#21841] bootstraptest is failed with OpenSUSE leap 16.0
by hsbt (Hiroshi SHIBATA) 18 Jan '26

18 Jan '26

Issue #21841 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21841: bootstraptest is failed with OpenSUSE leap 16.0 https://bugs.ruby-lang.org/issues/21841 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I update OpenSUSE leap instance to 16.0 from 15.x. After that, bootstraptest is failing with Ruby 3.2-3.4. Ruby 4.0 and master are working fine. Ruby 3.4: https://rubyci.s3.amazonaws.com/opensuseleap/ruby-3.4/log/20260115T223828Z.… ``` stderr output is not empty bootstraptest.test_jump.rb_299_735.rb: [BUG] Segmentation fault at 0x0000000000000000 ruby 3.4.8 (2026-01-06 revision c04363c0a0) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0001 p:0000 s:0003 E:000ad0 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x000055595d2a3ea0 RBP: 0x000000000000000d RSP: 0x00007ffc91829260 RAX: 0x000000000000000e RBX: 0x0000555990437ae0 RCX: 0x0000000000000000 RDX: 0x0000000000000000 RDI: 0x0000000000000007 RSI: 0x00007fd33607f081 R8: 0x045043922b485040 R9: 0x00007fd33607f081 R10: 0x0c0e0301ac9c2fcf R11: 0x000055595d56bf70 R12: 0x00007fd33607f0f1 R13: 0x00007fd33607f079 R14: 0x00005559905f88a8 R15: 0x00007fd33607f0ea EFL: 0x0000000000010256 -- C level backtrace information ------------------------------------------- /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/miniruby(rb_print_backtrace+0x5) [0x55595d35b136] /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/vm_dump.c:823 /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/miniruby(rb_vm_bugreport) /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/vm_dump.c:1155 /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/miniruby(rb_bug_for_fatal_signal+0xf7) [0x55595d0fc3c7] /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/error.c:1130 /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/miniruby(sigsegv+0x42) [0x55595d286f42] /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/signal.c:935 /lib64/libc.so.6(__restore_rt+0x0) [0x7fd335cb2090] /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/miniruby(search_nonascii+0xcb) [0x55595d2a3ea0] /home/chkbuild/chkbuild/tmp/build/20260115T223828Z/ruby/string.c:729 ... ``` Ruby 3.3: https://rubyci.s3.amazonaws.com/opensuseleap/ruby-3.3/log/20260115T224711Z.… ``` stderr output is not empty bootstraptest.test_syntax.rb_630_1458.rb: [BUG] Segmentation fault at 0x0000000000000000 ruby 3.3.10 (2025-12-15 revision 10876c271b) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0002 p:---- s:0006 e:000005 CFUNC :detailed_message c:0001 p:0000 s:0003 E:0018b0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- bootstraptest.test_syntax.rb_630_1458.rb:0:in `detailed_message' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x00005613f2267560 RBP: 0x000000000000000a RSP: 0x00007ffe1fb01f60 RAX: 0x000000000000000b RBX: 0x00005613ff3fb5c0 RCX: 0x0000000000000000 RDX: 0x0000000000000000 RDI: 0x0000000000000005 RSI: 0x00005613ff5537c7 R8: 0x0000000000000000 R9: 0x00005613ff5537c7 R10: 0x0000000000802005 R11: 0x00005613ff3e0950 R12: 0x00005613ff553824 R13: 0x00005613ff5537c7 R14: 0x0000000000000001 R15: 0x00005613ff55381d EFL: 0x0000000000010256 -- C level backtrace information ------------------------------------------- /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/miniruby(rb_print_backtrace+0x11) [0x5613f23190df] /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/vm_dump.c:820 /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/miniruby(rb_vm_bugreport) /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/vm_dump.c:1151 /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/miniruby(rb_bug_for_fatal_signal+0xf7) [0x5613f20cac37] /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/error.c:1065 /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/miniruby(sigsegv+0x4b) [0x5613f224cedb] /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/signal.c:928 /lib64/libc.so.6(__restore_rt+0x0) [0x7fce945e2090] /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/miniruby(search_nonascii+0xeb) [0x5613f2267560] /home/chkbuild/chkbuild/tmp/build/20260115T224711Z/ruby/string.c:598 ... ``` Ruby 3.2: https://rubyci.s3.amazonaws.com/opensuseleap/ruby-3.2/log/20260115T225525Z.… ``` /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/lib/mkmf.rb:2518: [BUG] Segmentation fault at 0x0000000000000000 ruby 3.2.10 (2026-01-14 revision a3a6d25788) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0013 p:---- s:0156 e:000155 CFUNC :% c:0012 p:1572 s:0151 E:001aa8 METHOD /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/lib/mkmf.rb:2518 c:0011 p:0060 s:0106 e:000105 METHOD ./ext/extmk.rb:144 c:0010 p:0067 s:0099 e:000098 METHOD ./ext/extmk.rb:565 c:0009 p:0043 s:0091 e:000090 TOP /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/ext/-test-/RUBY_ALIGNOF/extconf.rb:6 [FINISH] c:0008 p:---- s:0088 e:000087 CFUNC :load c:0007 p:0026 s:0083 e:000082 BLOCK ./ext/extmk.rb:229 c:0006 p:0022 s:0080 e:000079 METHOD /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/lib/mkmf.rb:324 c:0005 p:0554 s:0076 e:000075 METHOD ./ext/extmk.rb:225 c:0004 p:0039 s:0045 e:000044 BLOCK ./ext/extmk.rb:652 [FINISH] c:0003 p:---- s:0040 e:000039 CFUNC :each c:0002 p:0859 s:0036 E:002170 EVAL ./ext/extmk.rb:648 [FINISH] c:0001 p:0000 s:0003 E:001870 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- ./ext/extmk.rb:648:in `<main>' ./ext/extmk.rb:648:in `each' ./ext/extmk.rb:652:in `block in <main>' ./ext/extmk.rb:225:in `extmake' /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/lib/mkmf.rb:324:in `open' ./ext/extmk.rb:229:in `block in extmake' ./ext/extmk.rb:229:in `load' /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/ext/-test-/RUBY_ALIGNOF/extconf.rb:6:in `<top (required)>' ./ext/extmk.rb:565:in `create_makefile' ./ext/extmk.rb:144:in `create_makefile' /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/lib/mkmf.rb:2518:in `create_makefile' /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/lib/mkmf.rb:2518:in `%' -- Machine register context ------------------------------------------------ RIP: 0x000055b195f34b60 RBP: 0x00007f843e87b62f RSP: 0x00007ffd2427ffe8 RAX: 0x0000000000000000 RBX: 0x000055b1a8576710 RCX: 0x00007f843e87b637 RDX: 0x0000000000000000 RDI: 0x00007f843e87b673 RSI: 0x0000000000000008 R8: 0x00007f843e87b67a R9: 0x0000000000000004 R10: 0x00007f843e87b637 R11: 0x00007f843e87b610 R12: 0x0000000000000078 R13: 0x0000000000100000 R14: 0x00007f843e87b67a R15: 0x00007f843e87b610 EFL: 0x0000000000010256 -- C level backtrace information ------------------------------------------- /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/miniruby(rb_print_backtrace+0x11) [0x55b195feac68] /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/vm_dump.c:785 /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/miniruby(rb_vm_bugreport) /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/vm_dump.c:1080 /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/miniruby(rb_bug_for_fatal_signal+0xe7) [0x55b195d968d7] /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/error.c:813 /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/miniruby(sigsegv+0x4b) [0x55b195f1f97b] /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/signal.c:965 /lib64/libc.so.6(__restore_rt+0x0) [0x7f843ec46090] /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/miniruby(search_nonascii+0xf0) [0x55b195f34b60] /home/chkbuild/chkbuild/tmp/build/20260115T225525Z/ruby/string.c:660 ... ``` Does anyone know of a commit that might have fix this issue? -- https://bugs.ruby-lang.org/

2 3

[ruby-core:124587] [Ruby Bug#8743] Inconsistent behaviour calling public_methods on class (Plus documentation slightly ambiguous)
by trinistr (Alexander Bulancov) 18 Jan '26

18 Jan '26

Issue #8743 has been updated by trinistr (Alexander Bulancov). I've been working on some tests using `public_methods`, and was bitten by this. I think a documentation update is definitely needed. Docs shouldn't straight-up lie. Though I personally think that Module (or Class?) should just have different implementations of these methods. Current behavior makes some sense for instances, but for classes it's plain weird. ---------------------------------------- Bug #8743: Inconsistent behaviour calling public_methods on class (Plus documentation slightly ambiguous) https://bugs.ruby-lang.org/issues/8743#change-116168 * Author: stestagg (Steve Stagg) * Status: Closed * ruby -v: ruby 2.1.0dev (2013-08-06 trunk 42401) [x86_64-darwin12.4.0] ---------------------------------------- =begin = Background I was trying to identify classes on which a specific class method (def self.xx) was actually defined (in the case of multiple levels of inheritance). This currently doesn't seem to be possible, although the docs suggest that calling class.public_methods(false) should do this. While investigating, I discovered that the behaviour of calling instance.public_methods(false) is not consistent with that of calling class.public_methods(false) [They should be different, of course, but the behaviour should be consistent]. The attached test script highlights this. = Steps to Reproduce Run the attached ruby script = Expected Result Ideally, all tests pass, but at `least test_consistent_behaviour` should pass = Actual Results test_this_is_what_i_expect, and test_consistent_behaviour both fail. = Example test output steves@sapphire ~/s/t/ruby> env RUBYLIB=./lib ./ruby ~/foo.rb Run options: # Running tests: [2/5] PublicMethodsTest#test_consistent_behaviour = 0.00 s 1) Failure: PublicMethodsTest#test_consistent_behaviour [/Users/steves/foo.rb:73]: Differences: bar. "bar" is inherited from A, but doesn't include methods inherited from Object! [5/5] PublicMethodsTest#test_this_is_what_i_expect = 0.00 s 2) Failure: PublicMethodsTest#test_this_is_what_i_expect [/Users/steves/foo.rb:59]: Differences: allocate, new, superclass. Finished tests in 0.005998s, 833.6112 tests/s, 2834.2781 assertions/s. 5 tests, 17 assertions, 2 failures, 0 errors, 0 skips ruby -v: ruby 2.1.0dev (2013-08-06 trunk 42401) [x86_64-darwin12.4.0] Seen on ruby 1.8, 2.0 and trunk =end ---Files-------------------------------- foo.rb (2.22 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124443] [Ruby Bug#21828] An incorrect warning message related to `benchmark` is shown when using `benchmark-ips`
by y-yagi (Yuji Yaginuma) 18 Jan '26

18 Jan '26

Issue #21828 has been reported by y-yagi (Yuji Yaginuma). ---------------------------------------- Bug #21828: An incorrect warning message related to `benchmark` is shown when using `benchmark-ips` https://bugs.ruby-lang.org/issues/21828 * Author: y-yagi (Yuji Yaginuma) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Descrition When using `benchmark-ips` gem with Ruby 4.0.0, the warning related to `benchmark` gem is shown. ## Step to reproduce ```ruby # Gemfile # frozen_string_literal: true source "https://rubygems.org" gem "benchmark-ips" ``` ```ruby # script.rb require "benchmark/ips" ``` ```text $ bundle exec ruby -v script.rb ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] script.rb:1: warning: benchmark/ips is found in benchmark, which is not part of the default gems since Ruby 4.0.0. You can add benchmark to your Gemfile or gemspec to fix this error. ``` ## Expected behavior The warning for `benchmark` isn't shown when using `benchmark-ips`. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:124408] [Ruby Bug#21816] iseq code_location miss calculated indent
by zzak (zzak _) 16 Jan '26

16 Jan '26

Issue #21816 has been reported by zzak (zzak _). ---------------------------------------- Bug #21816: iseq code_location miss calculated indent https://bugs.ruby-lang.org/issues/21816 * Author: zzak (zzak _) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- TBH, I'm not really sure if that title matches the problem here, but I can produce this issue with the following test: ```ruby # bug.rb # note the indentation of the callable callable = -> { puts "Hello, World!" } iseq = RubyVM::InstructionSequence.of(callable) pp iseq.to_a pp iseq.to_a[4] pp iseq.to_a[4][:code_location][1] ``` Ruby 4.0.0: ``` $ ruby -v bug.rb ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] ["YARVInstructionSequence/SimpleDataFormat", 4, 0, 1, {arg_size: 0, local_size: 0, stack_max: 2, node_id: 7, code_location: [1, 15, 1, 40], node_ids: [4, 5, 4, 7], parser: :prism}, "block in <main>", "bug.rb", "/tmp/tmp.Fbq5WA0GnO/bug.rb", 1, :block, [], {}, [], [1, :RUBY_EVENT_LINE, :RUBY_EVENT_B_CALL, [:putself], [:putchilledstring, "Hello, World!"], [:opt_send_without_block, {mid: :puts, flag: 20, orig_argc: 1}], :RUBY_EVENT_B_RETURN, [:leave]]] {arg_size: 0, local_size: 0, stack_max: 2, node_id: 7, code_location: [1, 15, 1, 40], node_ids: [4, 5, 4, 7], parser: :prism} 15 ``` Ruby 4.1.0: ``` $ ruby -v bug.rb ruby 4.1.0dev (2025-12-30T18:02:00Z master 9d37155cfc) +PRISM [x86_64-linux] ["YARVInstructionSequence/SimpleDataFormat", 4, 1, 1, {arg_size: 0, local_size: 0, stack_max: 2, node_id: 7, code_location: [1, 13, 1, 40], node_ids: [4, 5, 4, 7], parser: :prism}, "block in <main>", "bug.rb", "/tmp/tmp.Fbq5WA0GnO/bug.rb", 1, :block, [], {}, [], [1, :RUBY_EVENT_LINE, :RUBY_EVENT_B_CALL, [:putself], [:putchilledstring, "Hello, World!"], [:opt_send_without_block, {mid: :puts, flag: 20, orig_argc: 1}], :RUBY_EVENT_B_RETURN, [:leave]]] {arg_size: 0, local_size: 0, stack_max: 2, node_id: 7, code_location: [1, 13, 1, 40], node_ids: [4, 5, 4, 7], parser: :prism} 13 ``` For context: This second value being 13 instead of 15 is causing Rails tests to fail: https://buildkite.com/rails/rails-nightly/builds/3447#019b710f-e78a-405f-82… We want: ``` { @object.num } ``` But we get: ``` -> { @object.num } ``` I am pretty sure using the same version of `prism`: ``` /tmp/tmp.Fbq5WA0GnO => rbenv shell 4.1.0 /tmp/tmp.Fbq5WA0GnO => gem list | grep prism prism (1.7.0) /tmp/tmp.Fbq5WA0GnO => rbenv shell 4.0.0 /tmp/tmp.Fbq5WA0GnO => gem list | grep prism prism (1.7.0) ``` We use this data to get the original source string of a block we use to decorate the `assert_difference` assertion: https://github.com/rails/rails/blob/3d31d593e6cf0f82fa9bd0338b635af2f30d627… https://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#m… -- https://bugs.ruby-lang.org/

4 5

[ruby-core:124054] [Ruby Misc#21768] Remove deprecated functions
by nobu (Nobuyoshi Nakada) 15 Jan '26

15 Jan '26

Issue #21768 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Misc #21768: Remove deprecated functions https://bugs.ruby-lang.org/issues/21768 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- -- https://bugs.ruby-lang.org/

4 3

[ruby-core:124047] [Ruby Feature#21766] Pathname + FileUtils making sweet music together
by gurgeous (Adam Doppelt) 15 Jan '26

15 Jan '26

Issue #21766 has been reported by gurgeous (Adam Doppelt). ---------------------------------------- Feature #21766: Pathname + FileUtils making sweet music together https://bugs.ruby-lang.org/issues/21766 * Author: gurgeous (Adam Doppelt) * Status: Open ---------------------------------------- I love Pathname. I love FileUtils. Let's bring these two classes EVEN CLOSER TOGETHER by adding some tragically missing helpers. Something like this, perhaps? ``` ruby class Pathname def mkdir_p(...) = FileUtils.mkdir_p(@path, ...) def ln(...) = FileUtils.ln(@path, ...) def ln_s(...) = FileUtils.ln_s(@path, ...) def ln_sf(...) = FileUtils.ln_sf(@path, ...) def cp(...) = FileUtils.cp(@path, ...) def cp_r(...) = FileUtils.cp_r(@path, ...) def mv(...) = FileUtils.mv(@path, ...) def rm(...) = FileUtils.rm(@path, ...) def rm_r(...) = FileUtils.rm_r(@path, ...) def rm_rf(...) = FileUtils.rm_rf(@path, ...) end ``` There are some concerns about making pathname.rb more dependent on FileUtils, which I understand. What's the best way forward? Let's do it! (also see https://github.com/ruby/pathname/issues/64 and https://github.com/ruby/pathname/issues/72) -- https://bugs.ruby-lang.org/

5 6

[ruby-core:124567] [Ruby Feature#13683] Add strict Enumerable#single
by headius (Charles Nutter) 15 Jan '26

15 Jan '26

Issue #13683 has been updated by headius (Charles Nutter). Of the proposed options I still like `one!` best. It conveys both returning a single element and enforcing that there's exactly one. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116141 * 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:124564] [Ruby Feature#13683] Add strict Enumerable#single
by Dan0042 (Daniel DeLorme) 15 Jan '26

15 Jan '26

Issue #13683 has been updated by Dan0042 (Daniel DeLorme). mame (Yusuke Endoh) wrote in #note-48: > But no one seriously considered it because we can find no use case for it. Uh, seriously? I gave an example in #note-16 and we have 11 other similar instances in our codebase. But none that raise an error. Pretty often used as `collection.compact.uniq.single` where we use it as default value for a new record if there is only one. Or, let's say search for product "ABC" and if there is only one match then redirect to it directly, otherwise display the search results. Anyway, I'm just giving my honest feedback. If if turns out the method raises an error, it's no big deal, I'll just keep using our own #single. Eregon (Benoit Daloze) wrote in #note-50: > then `ary.first if ary.size == 1` or so is good enough. That logic doesn't work at all. Of course it's "good enough" but in that case `raise if ary.size != 1` would also be "good enough". ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116138 * 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:124519] [Ruby Feature#21837] Introduce socket hooks in Fiber Scheduler interface
by noteflakes (Sharon Rosner) 15 Jan '26

15 Jan '26

Issue #21837 has been reported by noteflakes (Sharon Rosner). ---------------------------------------- Feature #21837: Introduce socket hooks in Fiber Scheduler interface https://bugs.ruby-lang.org/issues/21837 * Author: noteflakes (Sharon Rosner) * Status: Open ---------------------------------------- Currently the fiber scheduler interface does not support any socket operations. The stock Ruby socket implementation performs all operations in a non-blocking way, and invokes the `#io_wait` fiber scheduler hook in order to wait for readiness. I propose adding the following hooks: - `#socket_recv(sock, buffer, length, flags, recvfrom)`: performs a `recv` or `recvfrom`. The `recvfrom` argument is a boolean denoting whether a `recvfrom` should be performed. When true, the hook should return an array containing the number of bytes received and the source address. When false, the hook should return the number of bytes received. - `#socket_send(sock, dest, buffer, length, flags)`: performs a `send` or `sendto`. The `dest` argument is nil for a `send`. When not nil, a `sendto` operation should be done. - `#socket_connect(sock, addr)`: performs a `connect`. - `#socket_accept(sock, client_sockaddr)` - performs an `accept`. The `client_sockaddr` argument is an `IO::Buffer` that receives the peer addrinfo. The PR for this feature: https://github.com/ruby/ruby/pull/15865 -- https://bugs.ruby-lang.org/

2 2