August 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:116935] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
by nagachika (Tomoyuki Chikanaga) 22 Jan '26

22 Jan '26

Issue #18743 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED to 3.0: REQUIRED, 3.1: REQUIRED, 3.2: DONE ruby_3_2 5e4606423da96c2e26b00981c22bddfce0d970bf merged revision(s) f15123c34ce80f3928612befe2a9aaf4c9d27fda. ---------------------------------------- Bug #18743: Enumerator#next / peek re-use each others stacktraces https://bugs.ruby-lang.org/issues/18743#change-106970 * Author: sos4nt (Stefan Schüßler) * Status: Closed * Assignee: ko1 (Koichi Sasada) * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: DONE ---------------------------------------- I encountered an odd behavior. If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa) ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next # 5 ``` it will show the stacktrace from the rescued `peek` call: ``` $ ruby enum.rb enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` Whereas the error should refer to `next` on line number 5. The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls: ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next rescue nil # 5 enum.peek rescue nil # 6 puts "line #{__LINE__}" # 7 enum.next # 8 ``` The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location: ``` $ ruby enum.rb line 7 enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` This is very confusing when debugging code. ---Files-------------------------------- 01-Recreate-stacktrace-enumerator.patch (1.29 KB) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:112045] [Ruby master Bug#19378] Windows: Use less syscalls for faster require of big gems
by aidog (Andi Idogawa) 12 Jan '26

12 Jan '26

Issue #19378 has been reported by aidog (Andi Idogawa). ---------------------------------------- Bug #19378: Windows: Use less syscalls for faster require of big gems https://bugs.ruby-lang.org/issues/19378 * Author: aidog (Andi Idogawa) * Status: Open * Priority: Normal * ruby -v: 3.2.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hello 🙂 ## Problem require is slow on windows for big gems. (example: require 'gtk3'=> 3 seconds+). This is a problem for people who want to make cross platform GUI apps with ruby. ## Possible Reason As touched on in [#15797](https://bugs.ruby-lang.org/issues/15797) it seems like require uses realpath, which is emulated on windows. It checks every parent directory. The same syscalls run many times. ## Testfile C:\tmp\speedtest\testrequire.rb: ``` ruby require __dir__ + "/helloworld1.rb" require __dir__ + "/helloworld2.rb" ``` ``` shell ruby --disable-gems C:\tmp\speedtest\testrequire.rb ``` ### Syscalls per File/Directory: 1. CreateFile 2. QueryInformationVolume 3. QueryIdInformation 4. QueryAllInformationFile 5. QueryNameInformationFile 6. QueryNameInformationFile 7. QueryNormalizedNameInformationFile 8. CloseFile ### Files/Directories checked 1. C:\tmp 2. C:\tmp\speedtest 3. C:\tmp\speedtest\helloworld1.rb 4. C:\tmp 5. C:\tmp\speedtest 6. C:\tmp\speedtest\helloworld2.rb For two required files Ruby had to do 8*6 = **48** syscalls. The syscalls orginate from rb_w32_reparse_symlink_p / lstat Rubygems live in subfolders with 9+ parts: "C:\Ruby32-x64\lib\ruby\gems\3.2.0\gems\glib2-4.0.8\lib\glib2\variant.rb" Each file takes 8 * 9 = **72**+ calls. For variant.rb it is **80** calls. The result for the syscalls don't change in such a short time, so it should be possible to cache it. With require_relative it's twice as many calls. ## Other testcases Same result: ``` ruby File.realpath __dir__ + "/helloworld1.rb" File.realpath __dir__ + "/helloworld2.rb" ``` ``` ruby File.stat __dir__ + "/helloworld1.rb" File.stat __dir__ + "/helloworld2.rb" ``` It does not happen in $LOAD_PATH.resolve_feature_path(__dir__ + "/helloworld1.rb") ## Request Would it be possible to cache the stat calls when using require? I tried to implement a cache inside the ruby source code, but failed. If not, is there now a way to combine ruby files into one? I previously talked about require here: [YJIT: Windows support lacking.](https://bugs.ruby-lang.org/issues/19325#note-11) ## How to reproduce Ruby versions: At least 3.0+, most likely older ones too. Tested using Ruby Installer 3.1 and 3.2. [Procmon Software by Sysinternals](https://learn.microsoft.com/en-us/sysinternals/downloads/proc… -- https://bugs.ruby-lang.org/

6 7

[ruby-core:122552] [Ruby Feature#21442] Make tsort to bundled gems
by hsbt (Hiroshi SHIBATA) 08 Jan '26

08 Jan '26

Issue #21442 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21442: Make tsort to bundled gems https://bugs.ruby-lang.org/issues/21442 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- In last year, I gave up to make `tsort` to bundled gems because `set` depends `tsort`. https://github.com/ruby/set/blob/29a253d2259e8d6d9b313dec8418ec5ed0caab08/l… Fortunately, `set` is now core class. So, there is no library depends on `tsort` in ruby repository. I propose to make `tsort` to bundled gems at the next release(not Ruby 3.5/4.0, for 4.0(?)/4.1) -- https://bugs.ruby-lang.org/

1 3

[ruby-core:121699] [Ruby Feature#21277] Windows ARM support
by hsbt (Hiroshi SHIBATA) 08 Jan '26

08 Jan '26

Issue #21277 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21277: Windows ARM support https://bugs.ruby-lang.org/issues/21277 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I added the new CI job for Windows ARM support. * https://github.blog/changelog/2025-04-14-windows-arm64-hosted-runners-now-a… * https://github.com/ruby/ruby/pull/13118 We could build Ruby with Windows ARM platform. But `nmake check` is not working yet. I'm tracking that issues on this ticket. ## Can't generate `revision.h` `windows-11-arm` runner couldn't generate `revision.h` with `ruby tool/file2lastrev.rb --revision.h --output=revision.h`. I tried that with git provided by `scoop`. But that is also not working. I confirmed to work `git rev-parse HEAD` directly with `pwsh` of GitHub Actions. But `tool/file2lastrev.rb` returns the followings: ``` Run ruby tool/file2lastrev.rb --revision.h --output=revision.h file2lastrev.rb: git rev-parse failed fatal: unable to access 'NUL': Invalid argument ``` ## `nmake check` is not working https://github.com/ruby/ruby/actions/runs/14564201209/job/40851166866 ``` running file: C:/a/ruby/ruby/src/test/rubygems/test_gem_resolver_index_set.rb A test worker crashed. It might be an interpreter bug or a bug in test/unit/parallel.rb. Try again without the -j option. ``` https://github.com/ruby/ruby/actions/runs/14564667517/job/40852193517 ``` NMAKE : fatal error U1077: '@ .\ruby.exe -I../src/lib -I".ext/arm64-mswin64_140" -I. "../src/tool/runruby.rb" --extout=".ext" -- --disable-gems -r./arm64-mswin64_140-fake -r../src/tool/lib/_tmpdir ../src/spec/mspec/bin/mspec run -B ../src/spec/default.mspec ' : return code '0xc0000005' Stop. ``` They may be caused by Visual Studio 2022 issue same as #21255. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:120488] [Ruby master Feature#21005] Update the source location method to include line start/stop and column start/stop details
by bkuhlmann (Brooke Kuhlmann) 30 Dec '25

30 Dec '25

Issue #21005 has been reported by bkuhlmann (Brooke Kuhlmann). ---------------------------------------- Feature #21005: Update the source location method to include line start/stop and column start/stop details https://bugs.ruby-lang.org/issues/21005 * Author: bkuhlmann (Brooke Kuhlmann) * Status: Open ---------------------------------------- ## Why 👋 Hello. After discussing with Kevin Newton and Benoit Daloze in [Feature 20999](https://bugs.ruby-lang.org/issues/20999), I'd like to propose adding line start/stop and column start/stop information to the `#source_location` method for the following objects: - [Binding](https://docs.ruby-lang.org/en/master/Binding.html) - [Proc](https://docs.ruby-lang.org/en/master/Proc.html) - [Method](https://docs.ruby-lang.org/en/master/Method.html) - [UnboundMethod](https://docs.ruby-lang.org/en/master/UnboundMethod.html) At the moment, when using `#source_location`, you only get the following information: ``` ruby def demo = "A demonstration." # From disk. method(:demo).source_location # ["/Users/bkuhlmann/Engineering/Misc/demo", 15] # From memory. method(:demo).source_location # ["(irb)", 3] ``` Notice, when asking for the source location, we only get the path/location as the first element and the line number as the second element but I'd like to obtain a much richer set of data which includes line start/stop and column start/stop so I can avoid leaning on the `RubyVM` for this information. Example: ``` ruby def demo = "A demonstration." # From disk. instructions = RubyVM::InstructionSequence.of method(:demo) puts [instructions.absolute_path, *instructions.to_a.dig(4, :code_location)] [ "/Users/bkuhlmann/Engineering/Misc/demo", # Source path. 15, # Line start. 0, # Column start. 15, # Line stop. 29 # Column stop. ] # From memory. instructions = RubyVM::InstructionSequence.of method(:demo) puts instructions.script_lines [ "def demo = \"A demonstration.\"\n", "" ] ``` By having access to the path (or lack thereof in case of IRB), line start/stop, and column start/stop, this means we could avoid using the RubyVM to obtain raw source code for any of these objects. This would not only enhance debugging situations but also improve Domain Specific Languages that wish to leverage this information for introducing new features and/or new debugging capabilities to the language. ## How Building upon the examples provided above, I'd like to see `Binding`, `Proc`, `Method`, and `UnboundMethod` respond to `#source_location` as follows: ``` ruby [ "/Users/bkuhlmann/Engineering/Misc/demo", # Source path. 15, # Line start. 15, # Line stop. 0, # Column start. 29 # Column stop. ] ``` Notice, for data grouping purposes, I changed the array structure to always start with the path as the first element, followed by line information, and ending with column information. Alternatively, it could might be nice to improve upon the above by answering a hash each time, instead, for a more self-describing data structure. Example: ``` ruby { path: "/Users/bkuhlmann/Engineering/Misc/demo", line_start: 15, line_stop: 15, column_start: 0, column_stop: 29 } ``` For in-memory, situations like IRB, it would be nice to answer the equivalent of `RubyVM::InstructionSequence#script_lines` which would always be an `Array` with no line or column information since only the source code is necessary. Example: ``` ruby [ "def demo = \"A demonstration.\"\n", "" ] ``` From a pattern matching perspective, this could provide the best of both worlds especially if information is answered as either a `Hash` or and `Array`. Example: ``` def demo = "A demonstration." case method(:demo).source_location in Hash then puts "Source information obtained from disk." in Array then puts "Source obtained from memory." else fail TypeError, "Unrecognized source location type." end ``` This above is only a simple example but there's a lot we could do with this information if the above pattern match was enhanced to deal with the extraction and formatting of the actual source code! ## Notes This feature request is related to the following discussions in case more context is of help: - [Feature 6012](https://bugs.ruby-lang.org/issues/6012) - [Feature 20999](https://bugs.ruby-lang.org/issues/20999) -- https://bugs.ruby-lang.org/

8 19

[ruby-core:120749] [Ruby master Feature#21084] Declare objects have weak references
by peterzhu2118 (Peter Zhu) 30 Dec '25

30 Dec '25

Issue #21084 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #21084: Declare objects have weak references https://bugs.ruby-lang.org/issues/21084 * Author: peterzhu2118 (Peter Zhu) * Status: Open ---------------------------------------- # Summary The current way of marking weak references uses `rb_gc_mark_weak(VALUE *ptr)`. This presents challenges because Ruby's GC is incremental, meaning that if the `ptr` changes (e.g. realloc'd or free'd), then we could have an invalid memory access. This also overwrites `*ptr = Qundef` if `*ptr` is dead, which prevents any cleanup to be run (e.g. freeing memory or deleting entries from hash tables). This ticket proposes `rb_gc_declare_weak_references` which declares that an object has weak references and calls a cleanup function after marking, allowing the object to clean up any memory for dead objects. # Introduction In [[Feature #19783]](https://bugs.ruby-lang.org/issues/19783), I introduced an API allowing objects to mark weak references, the function signature looks like this: ```c void rb_gc_mark_weak(VALUE *ptr); ``` `rb_gc_mark_weak` is called during the marking phase of the GC to specify that the memory at `ptr` holds a pointer to a Ruby object that is weakly referenced. `rb_gc_mark_weak` appends this pointer to a list that is processed after the marking phase of the GC. If the object at `*ptr` is no longer alive, then it overwrites the object reference with a special value (`*ptr = Qundef`). However, this API resulted in two challenges: 1. Ruby's default GC is incremental, which means that the GC is not ran in one phase, but rather split into chunks of work that interleaves with Ruby execution. The `ptr` passed into `rb_gc_mark_weak` could be on the malloc heap, and that memory could be realloc'd or even free'd. We had to use workarounds such as `rb_gc_remove_weak` to ensure that there were no illegal memory accesses. This made `rb_gc_mark_weak` difficult to use, impacted runtime performance, and increased memory usage. 2. When an object dies, `rb_gc_mark_weak` only overwites the reference with `Qundef`. This means that if we want to do any cleanup (e.g. free a piece of memory or delete a hash table entry), we could not do that and had to defer this process elsewhere (e.g. during marking or runtime). # Declarative weak references In this ticket, I'm proposing a new API for weak references. Instead of an object marking its weak references during the marking phase, the object declares that it has weak references using the `rb_gc_declare_weak_references` function. This declaration occurs during runtime (e.g. after the object has been created) rather than during GC. After an object declares that it has weak references, it will have its callback function called after marking as long as that object is alive. This callback function can then call a special function `rb_gc_handle_weak_references_alive_p` to determine whether its references are alive. This will allow the callback function to do whatever it wants on the object, allowing it to perform any cleanup work it needs. This significantly simplifies the code for `ObjectSpace::WeakMap` and `ObjectSpace::WeakKeyMap` because it no longer needs to have the workarounds for the limitations of `rb_gc_mark_weak`. # Performance The performance results below demonstrate that `ObjectSpace::WeakMap#[]=` is now about 60% faster because the implementation has been simplified and the number of allocations has been reduced. We can see that there is not a significant impact on the performance of `ObjectSpace::WeakMap#[]`. Base: ``` ObjectSpace::WeakMap#[]= 4.620M (± 6.4%) i/s (216.44 ns/i) - 23.342M in 5.072149s ObjectSpace::WeakMap#[] 30.967M (± 1.9%) i/s (32.29 ns/i) - 154.998M in 5.007157s ``` Branch: ``` ObjectSpace::WeakMap#[]= 7.336M (± 2.8%) i/s (136.31 ns/i) - 36.755M in 5.013983s ObjectSpace::WeakMap#[] 30.902M (± 5.4%) i/s (32.36 ns/i) - 155.901M in 5.064060s ``` Code: ``` require "bundler/inline" gemfile do source "https://rubygems.org" gem "benchmark-ips" end wmap = ObjectSpace::WeakMap.new key = Object.new val = Object.new wmap[key] = val Benchmark.ips do |x| x.report("ObjectSpace::WeakMap#[]=") do |times| i = 0 while i < times wmap[Object.new] = Object.new i += 1 end end x.report("ObjectSpace::WeakMap#[]") do |times| i = 0 while i < times wmap[key] wmap[val] # does not exist i += 1 end end end ``` # Alternative designs Currently, `rb_gc_declare_weak_references` is designed to be an internal-only API. This allows us to assume the object types that call `rb_gc_declare_weak_references`. In the future, if we want to open up this API to third parties, we may want to change this function to something like: ```c void rb_gc_add_cleaner(VALUE obj, void (*callback)(VALUE obj)); ``` This will allow the third party to implement a custom `callback` that gets called after the marking phase of GC to clean up any dead references. I chose not to implement this design because it is less efficient as we would need to store a mapping from `obj` to `callback`, which requires extra memory. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:121234] [Ruby master Bug#21168] Prism doesn't require argument parentheses (in some cases) when a block is present but parse.y does
by Earlopain (Earlopain _) 28 Dec '25

28 Dec '25

Issue #21168 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21168: Prism doesn't require argument parentheses (in some cases) when a block is present but parse.y does https://bugs.ruby-lang.org/issues/21168 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- It's a bit more than that but explaining it in full would be a bit much. Instead, see this: ```rb foo( bar baz do end ) ``` ```sh $ ruby -c --parser=prism test.rb Syntax OK $ ruby -c --parser=parse.y test.rb ruby: test.rb:2: syntax error, unexpected 'do' for block, expecting ')' (SyntaxError) bar baz do ^~ ``` OTOH, this is consistently rejected: ```rb [ foo bar do end, ] # And also foo || bar baz do end ``` -- https://bugs.ruby-lang.org/

7 9

[ruby-core:121642] [Ruby Bug#21266] YJIT GC safety crash with proc objects as block argument
by alanwu (Alan Wu) 19 Dec '25

19 Dec '25

Issue #21266 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #21266: YJIT GC safety crash with proc objects as block argument https://bugs.ruby-lang.org/issues/21266 * Author: alanwu (Alan Wu) * Status: Open * Assignee: yjit * Backport: 3.2: DONTNEED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- ```ruby # Run with --yjit-call-threshold=1 def foo(args) = bar(*args, &proc { _1 }) def bar(_, _, _, _, *rest) = yield rest GC.stress = true foo([1,2,3,4]) foo([1,2,3,4]) ``` The proc in these calls get collected on the yield to the GC to allocate the rest parameter arary. ``` ../vm_core.h:1668: Assertion Failed: vm_block_handler_type:rb_obj_is_proc(block_handler) ``` Or in release builds: ``` ../test.rb:1: [BUG] Segmentation fault at 0x0000000000000020 ruby 3.3.6 (2024-11-05 revision 75015d4c1f) +YJIT [arm64-darwin24] -- C level backtrace information ------------------------------------------- /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_vm_bugreport+0xb4c) [0x104595590] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_bug_for_fatal_signal+0x100) [0x1043d6120] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(sig_do_nothing+0x0) [0x1044fc4b0] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x187572de4] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_vm_invokeblock+0x144) [0x10456b004] ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:118957] [Ruby master Bug#20699] On Windows, the `__dir__` keyword is garbled in paths containing Japanese characters, and `require_relative` fails as well
by flatland001 (Hayato Arai) 18 Dec '25

18 Dec '25

Issue #20699 has been reported by flatland001 (Hayato Arai). ---------------------------------------- Bug #20699: On Windows, the `__dir__` keyword is garbled in paths containing Japanese characters, and `require_relative` fails as well https://bugs.ruby-lang.org/issues/20699 * Author: flatland001 (Hayato Arai) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x64-mingw-ucrt] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In paths containing Japanese characters, such as: C:\テスト_test\test.rb Code: ``` ruby # this code -> C:\テスト_test\test.rb # external file -> C:\テスト_test\lib\foo.rb p __dir__ p __dir__.encoding p File.dirname(File.expand_path(__FILE__)) p File.dirname(File.expand_path(__FILE__)).encoding print "__dir__ == File.dirname(File.expand_path(__FILE__)): " p __dir__ == File.dirname(File.expand_path(__FILE__)) begin require_relative "lib/foo" puts "foo.rb loaded" rescue LoadError puts "LoadError: #{$!}" end ``` Results: ``` "C:/?e?X?g_test" #<Encoding:Windows-31J> "C:/\x{8365}\x{8358}\x{8367}_test" #<Encoding:Windows-31J> __dir__ == File.dirname(File.expand_path(__FILE__)): false LoadError: cannot load such file -- C:/?e?X?g_test/lib/foo ``` However, in ruby 3.2.5 (2024-07-26 revision 31d0f1a2e7) [x64-mingw-ucrt], the same code produces the following expected results: ``` "C:/\x{8365}\x{8358}\x{8367}_test" #<Encoding:Windows-31J> "C:/\x{8365}\x{8358}\x{8367}_test" #<Encoding:Windows-31J> __dir__ == File.dirname(File.expand_path(__FILE__)): true foo.rb loaded ``` Is this behavior expected, or could this be a bug in the Ruby interpreter on Windows? If this is my misunderstanding or a known issue, I apologize. Thank you for your consideration. Environment Information: - OS: Windows 11 Pro 23H2 (OS build 22631.4037) - Installed via: RubyInstaller - Shell: Command Prompt - File System: NTFS - System Locale: Japanese (Japan), Language: Japanese -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120743] [Ruby master Bug#21049] Reconsider handling of the numbered parameters and "it" parameter in `Binding#local_variables`
by mame (Yusuke Endoh) 18 Dec '25

18 Dec '25

Issue #21049 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #21049: Reconsider handling of the numbered parameters and "it" parameter in `Binding#local_variables` https://bugs.ruby-lang.org/issues/21049 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: matz (Yukihiro Matsumoto) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Currently, `Binding#local_variable*` APIs wrongly handles the numbered parameters. ```ruby # Binding#local_variables includes numbered parameters that should not be visible "foo".tap do _1 "bar".tap do p binding.local_variables #=> expected: [], actual: [:_1] end end # Binding#local_variable_get can read numbered parameters that should not be readable "foo".tap do _1 "bar".tap do p binding.local_variable_get(:_1) #=> expected: NameError, actual: "foo" end end # Binding#local_variable_set can update numbered parameter "foo".tap do p _1 #=> "foo" binding.local_variable_set(:_1, "bar") # expected: NameError, actual: updates _1 p _1 #=> "bar" end ``` My proposal is to stop handling numbered parameters and "it" parameter in `Binding#local_variable*` APIs. ```ruby "foo".tap do _1 binding.local_variables #=> proposed: [] binding.local_variable_get(:_1) #=> proposed: NameError end ``` Here is a proof-of-concept patch. https://github.com/ruby/ruby/pull/12601 It would be theoretically possible to fix `Binding#local_variable*` APIs to handle numbered parameters while maintaining compatibility as much as possible. However, I think the implicit “it” parameter introduced in Ruby 3.4 poses a spec-level problem. This is because there is no way to distinguish between the implicit “it” parameter and a true local variable named "it". Also, I don't think numbered parameters are local variables, so I feel uncomfortable handling them by `Binding#local_variable*` APIs. If it is absolutely necessary to access numbered parameters or "it" parameter via binding, it would be good to introduce dedicated APIs for the purpose, as: * Binding#numbered_parameters #=> [:_1, :_2, :_3, ...] * Binding#numbered_parameter_get(:_1) #=> obj * Binding#numbered_parameter_defined?(:_1) #=> true or false * Binding#it_get #=> obj * Binding#it_defined? #=> true or false Personally, however, I do not see the need for these APIs currently. I implemented them as proof-of-concept in PR, but I am okay that they are not introduced. -- https://bugs.ruby-lang.org/

3 5