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

[ruby-core:115196] [Ruby master Feature#19979] Allow methods to declare that they don't accept a block via `&nil`
by ufuk (Ufuk Kayserilioglu) 15 Feb '26

15 Feb '26

Issue #19979 has been reported by ufuk (Ufuk Kayserilioglu). ---------------------------------------- Feature #19979: Allow methods to declare that they don't accept a block via `&nil` https://bugs.ruby-lang.org/issues/19979 * Author: ufuk (Ufuk Kayserilioglu) * Status: Open * Priority: Normal ---------------------------------------- ## Abstract This feature proposes new syntax to allow methods to explicitly declare that they don't accept blocks, and makes passing of a block to such methods an error. ## Background In #15554, it was proposed to automatically detect methods that do not use the block passed to them, and to error if a block was passed to such methods. As far as I can tell, it was later on closed since #10499 solved a large part of the problem. That proposal has, as part of the dev meeting discussion, a proposal from @matz to allow methods to use `&nil` to explicitly declare that they don't accept a block. At the time, the proposal was trying to solve a bigger problem, so this sub-proposal was never considered seriously. However, notes in the proposal say: > It is explicit, but it is tough to add this `&nil` parameter declaration to all of methods (do you want to add it to `def []=(i, e, &nil)`?). (I agree `&nil` is valuable on some situations) This proposal extracts that sub-proposal to make this a new language feature. ## Proposal In Ruby, it is always valid for the caller to pass a block to a method call, even if the callee is not expecting a block to be passed. This leads to subtle user errors, where the author of some code assumes a method call uses a block, but the block passed to the method call is silently ignored. The proposal is to introduce `&nil` at method declaration sites to mean "This method does not accept a block". This is symmetric to the ability to pass `&nil` at call sites to mean "I am not passing a block to this method call", which is sometimes useful when making `super` calls (since blocks are always implicitly passed). Explicitly, the proposal is to make the following behaviour be a part of Ruby: ```ruby def find(item = nil, &nil) # some implementation that doesn't call `yield` or `block_given?` end find { |i| i == 42 } # => ArgumentError: passing block to the method `find' that does not accept a block. ``` ## Implementation I assume the implementation would be a grammar change to make `&nil` valid at method declaration sites, as well as raising an `ArgumentError` for methods that are called with a block but are declared with `&nil`. ## Evaluation Since I don't have an implementation, I can't make a proper evaluation of the feature proposal. However, I would expect the language changes to be minimal with no runtime costs for methods that don't use the `&nil` syntax. ## Discussion This proposal has much smaller scope than #15554 so that the Ruby language can start giving library authors the ability to explicitly mark their methods as not accepting a block. This is fully backward compatible, since it is an opt-in behaviour and not an opt-out one. Future directions after this feature proposal could be a way to signal to the VM that any method in a file that doesn't explicitly use `yield`/`block_given?` or explicitly declared a block parameter should be treated as not accepting a block. This can be done via some kind of pragma similar to `frozen_string_literal`, or through other means. However, such future directions are beyond the scope of this proposal. ## Summary Adding the ability for methods to declare that they don't accept a block will make writing code against such methods safer and more resilient, and will prevent silently ignored behaviour that is often hard to catch or troubleshoot. -- https://bugs.ruby-lang.org/

10 25

[ruby-core:124461] [Ruby Bug#21830] Ruby::Box and Kernel#require
by fxn (Xavier Noria) 15 Feb '26

15 Feb '26

Issue #21830 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21830: Ruby::Box and Kernel#require https://bugs.ruby-lang.org/issues/21830 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- If you enable `Ruby::Box`, decorations to `Kernel#require` do not work. For example, given `foo.rb`: ```ruby # foo.rb % cat foo.rb module M def require(_path) puts "decorated" super end end Kernel.prepend(M) require 'tsort' ``` the decoration works normally: ``` % ruby -v foo.rb ruby 4.0.0 (2025-12-25 revision 553f1675f3) +YJIT +PRISM [arm64-darwin25] decorated ``` and the same code does not work with the feature enabled: ``` % RUBY_BOX=1 ruby -v foo.rb ruby 4.0.0 (2025-12-25 revision 553f1675f3) +YJIT +PRISM [arm64-darwin25] ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See https://docs.ruby-lang.org/en/4.0/Ruby/Box.html for known issues, etc. ``` With this, Zeitwerk cannot work because it totally depends on `Kernel#require` decoration (done [here](https://github.com/fxn/zeitwerk/blob/main/lib/zeitwerk/core_ext/kerne…) Bootsnap also depends on the ability of decorating `Kernel#require` (done [here](https://github.com/rails/bootsnap/blob/main/lib/bootsnap/load_path_ca…) On one hand, these gems are walking a fine line in the border of the public interface of Ruby. On the other hand, it is a goal of boxes to be transparent to the code being loaded under them. @tagomoris what should be the way to go in your opinion? /cc @byroot -- https://bugs.ruby-lang.org/

2 4

[ruby-core:121988] [Ruby Bug#21324] Namespace loads RubyGems in root Namespace but it should not
by Eregon (Benoit Daloze) 15 Feb '26

15 Feb '26

Issue #21324 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21324: Namespace loads RubyGems in root Namespace but it should not https://bugs.ruby-lang.org/issues/21324 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- RubyGems has tons of mutable state, isn't core library and isn't "builtin classes" either, so it should not be in root Namespace, as it is currently: ``` $ RUBY_NAMESPACE=1 ruby -ve 'ns = Namespace.new; p ns::Gem.equal?(Gem)' ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for know issues, etc. true ``` A concrete example of what breaks most likely due to this: ``` $ gem i delegate:0.3.1 $ RUBY_NAMESPACE=1 ruby -ve 'require "delegate"; p Delegator::VERSION; ns = Namespace.new; File.write "ns.rb", "gem %{delegate}, %{0.3.1}; require :delegate.to_s; p Delegator::VERSION"; ns.require "./ns"' ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for know issues, etc. "0.4.0" /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/specification.rb:2232:in 'Gem::Specification#check_version_conflict': can't activate delegate-0.3.1, already activated delegate-0.4.0 (Gem::LoadError) from /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/specification.rb:1383:in 'Gem::Specification#activate' from /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_gem.rb:62:in 'block in Kernel#gem' from /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_gem.rb:62:in 'Thread::Mutex#synchronize' from /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_gem.rb:62:in 'Kernel#gem' from /home/eregon/ns.rb:1:in '<top (required)>' from -e:1:in 'Namespace#require' from -e:1:in '<main>' ``` i.e. `ns` sees delegate-0.4.0 was loaded in main namespace but it shouldn't. Previously mentioned in https://bugs.ruby-lang.org/issues/21311#note-36 -- https://bugs.ruby-lang.org/

5 8

[ruby-core:124198] [Ruby Feature#21781] Add `fetch_values` method on `ENV`
by Earlopain (Earlopain _) 14 Feb '26

14 Feb '26

Issue #21781 has been reported by Earlopain (Earlopain _). ---------------------------------------- Feature #21781: Add `fetch_values` method on `ENV` https://bugs.ruby-lang.org/issues/21781 * Author: Earlopain (Earlopain _) * Status: Open ---------------------------------------- In https://bugs.ruby-lang.org/issues/10017, `fetch_values` was introduced for `Hash`. `ENV` is hash-like but is missing the method. Here are the differences between hash and env right now: ```rb irb(main):006> Hash.instance_methods - ENV.methods => [:merge, :compare_by_identity, :compare_by_identity?, :>=, :deconstruct_keys, :dig, :<=, :>, :<, :to_proc, :flatten, :compact!, :default=, :default_proc, :default_proc=, :default, :transform_keys, :transform_keys!, :transform_values!, :fetch_values, :transform_values] ``` `flatten`/`dig` among others make no sense for `ENV`. Some I don't see why they are not present but I won't argue for them since I have no use-case. Here is code I wanted to write: ```rb # Get many env variables and crash if one is missing user, pass, year, target_dir = ENV.fetch_values("USER", "PASS", "YEAR", "TARGET_DIR") ``` For now I am simply adding `to_h` and all is good. But should I have to? Ignoring a small amount of methods, ENV is very close to a hash already. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:124311] [Ruby Feature#21795] Methods for retrieving ASTs
by kddnewton (Kevin Newton) 14 Feb '26

14 Feb '26

Issue #21795 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #21795: Methods for retrieving ASTs https://bugs.ruby-lang.org/issues/21795 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- I would like to propose a handful of methods for retrieving ASTs from various objects that correspond to locations in code. This includes: * Proc#ast * Method#ast * UnboundMethod#ast * Thread::Backtrace::Location#ast * TracePoint#ast (on call/return events) The purpose of this is to make tooling easier to write and maintain. Specifically, this would be able to be used in irb, power_assert, error_highlight, and various other tools both in core and not that make use of source code. There have been many previous discussions of retrieving node_id, source_location, source, etc. All of these use cases are covered by returning the AST for some entity. In this case node_id becomes an implementation detail, invisible to the user. Source location can be derived from the information on the AST itself. Similarly, source can be derived from the AST. Internally, I do not think we have to store any more information than we already do (since we have node_id for the first four of these, it becomes rather trivial). For TracePoint we can have a larger discussion about it, but I think it should not be too much work. In terms of implementation, the only caveat I would put is that if the ISEQ were compiled through the old parser/compiler, this should return `nil`, as the node ids do not match up and we do not want to further propagate the RubyVM::AST API. The reason I am opening up this ticket with 5 different methods requested in it is to get approval first for the direction, then I can open individual tickets or just PRs for each method. I believe this feature would ease the maintenance burden of many core libraries, and unify otherwise disparate efforts to achieve the same thing. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:124821] [Ruby Feature#17513] Methods of shareable objects and UnboundMethods should be shareable
by trinistr (Alexander Bulancov) 13 Feb '26

13 Feb '26

Issue #17513 has been updated by trinistr (Alexander Bulancov). A `def`-ed method of a shareable object may depend on unshareable state. Even worse, shareability of state may dynamically change: ```ruby module Checker CHECK = [] def check? CHECK.include?(self) end end class A; include Checker; end obj = A.new.freeze Ractor.shareable?(obj) # => true Ractor.new(obj) { |o| p o.check? } # Ractor::IsolationError Checker::CHECK.freeze Ractor.new(A.new.freeze) { |o| p o.check? } # false Checker::CHECK = [] # And here we go again ``` ---------------------------------------- Feature #17513: Methods of shareable objects and UnboundMethods should be shareable https://bugs.ruby-lang.org/issues/17513#change-116442 * Author: marcandre (Marc-Andre Lafortune) * Status: Assigned * Assignee: ko1 (Koichi Sasada) ---------------------------------------- ```ruby class Foo def foo end end f = Foo.new.freeze Ractor.shareable?(f) # => true Ractor.make_shareable(f.method(:foo).to_proc) # => Proc, ok Ractor.make_shareable(f.method(:foo)) # => Ractor::Error, expected Method Ractor.make_shareable(Foo.instance_method(:foo)) # => Ractor::Error, expected UnboundMethod ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124820] [Ruby Feature#6478] BasicObject#__class__
by trinistr (Alexander Bulancov) 13 Feb '26

13 Feb '26

Issue #6478 has been updated by trinistr (Alexander Bulancov). jneen (Jeanine Adkisson) wrote in #note-16: > I wonder if exposing a static `Object.class_of(thing)` would be appropriate? There's also the singleton_class to consider as well. This is an interesting idea. It would solve the problems around this, in a simpler way than an `UnboundMethod`. But it defintely feels off for Ruby, though we have some methods like that (`Regexp.linear_time?` comes to mind). Eregon (Benoit Daloze) wrote in #note-19: > I think at least it's clear it's not good to go towards having every `Kernel` method as a `__x__` variant on BasicObject. > Also even `__send__` and `__id__` can be redefined, so the `KERNEL_CLASS = Kernel.instance_method(:class); KERNEL_CLASS.bind_call(obj)` approach is in fact safer. > > So my take on this is `KERNEL_CLASS = Kernel.instance_method(:class); KERNEL_CLASS.bind_call(obj)` is good enough, > and also most BasicObject subclasses should implement Kernel-like methods. > > Concrete examples from real code where this is not good enough would most likely be helpful to move this forward if people want that. I agree, porting all methods from Kernel is unreasonable. It's just that having access to object's class is fundamental and would provide replacements for many generic methods (especially `methods` and co). In my experience, `__class__` would be much more useful than `__id__`, for example. IMHO, redefining basic methods is not a compelling argument, `Kernel#class` could be redefined too. On the other hand, `#class` being redefined [happens](https://github.com/search?q=%2Fdef+class%5Cb%2F+language%3Aruby&re… more often than for `#__class__`. > `KERNEL_CLASS = Kernel.instance_method(:class)` This looks even less Ruby-like to me than a silly method name :p Also, due to constant resolution, placing such constants requires extra consideration or littering the code with them. > Concrete examples from real code where this is not good enough would most likely be helpful to move this forward if people want that. ```ruby Ractor.shareable?(Kernel.instance_method(:class)) # => false ``` So Ractor-compatible code can not use such a constant (relevant #17513 is still open). And just basic stuff like this would be much easier to write: ```ruby def my_chunkers(collection) raise ArgumentError, "#{collection.__class__} is not enumerable" unless Enumerable === collection collection.chunk(&:itself) end ``` byroot (Jean Boussier) wrote in #note-18: > > Why not add BasicObject#class? > > I suspect that would break various proxy classes in gems. Might not be a huge deal. That's that I thought, too, there probably is code relying on `class` being proxied, otherwise I would push for that name. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116441 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124660] [Ruby Feature#21858] `Kernel#Hash` considers `to_h` too
by ccmywish (Aoran Zeng) 13 Feb '26

13 Feb '26

Issue #21858 has been reported by ccmywish (Aoran Zeng). ---------------------------------------- Feature #21858: `Kernel#Hash` considers `to_h` too https://bugs.ruby-lang.org/issues/21858 * Author: ccmywish (Aoran Zeng) * Status: Open ---------------------------------------- 1. `Kernel#Integer` uses `to_int` first and `to_i` second 2. `Kernel#Array` uses `to_ary` first and `to_a` second 3. `Kernel#Hash` only uses `to_hash` I don't quite understand why there is a need for differential treatment here. I admit that maybe the only benefit of considering `to_h` secondly is that it enables multiple APIs to maintain consistency. -- https://bugs.ruby-lang.org/

4 8

[ruby-core:124811] [Ruby Feature#21878] More file types: DOOR, PORT, WHITEOUT
by nobu (Nobuyoshi Nakada) 13 Feb '26

13 Feb '26

Issue #21878 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #21878: More file types: DOOR, PORT, WHITEOUT https://bugs.ruby-lang.org/issues/21878 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- I found recent Python supports these file types: [S_ISDOOR](https://docs.python.org/3.14/library/stat.html#stat.S_ISDOOR) [S_ISPORT](https://docs.python.org/3.14/library/stat.html#stat.S_ISPORT) [S_ISWHT](https://docs.python.org/3.14/library/stat.html#stat.S_ISWHT) even they [return `False` always](https://github.com/python/cpython/blob/3.14/Lib/stat.py#L78-L88). What about supporting them in Ruby? -- https://bugs.ruby-lang.org/

4 3

[ruby-core:124342] [Ruby Feature#21800] `Dir.foreach` and `Dir.each_child` to optionally yield `File::Stat` object alongside the children name
by byroot (Jean Boussier) 13 Feb '26

13 Feb '26

Issue #21800 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21800: `Dir.foreach` and `Dir.each_child` to optionally yield `File::Stat` object alongside the children name https://bugs.ruby-lang.org/issues/21800 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- When listing a directory, it's very common to need to know the type of each children, generally because you want to scan recursively. The naive way to do this is to call `stat(2)` for each children, but this is quite costly. This use case is common enough that `readdir` on most modern platforms do expose `struct dirent.d_type`, which allows to know the type of the child without an extra syscall. I wrote a quick prototype, and relying on `dirent.d_type` instead of `stat(2)` allows to recursively scan Ruby's repository twice as fast on my machine: https://github.com/ruby/ruby/pull/15667 Given that recursively scanning directories is a common task across many popular ruby tools (`zeitwerk`, `rubocop`, etc), I think it would be very valuable to provide this more efficient interface. In addition, @nobu noticed my prototype, and implemented a nicer version of it, where a `File::Stat` is yielded: https://github.com/ruby/ruby/commit/9acf67057b9bc6f855b2c37e41c1a2f91eae643a In that case the `File::Stat` is lazy, it's only if you access something other than file type, that the actual `stat(2)` call is emitted. I think this API is both more efficient and more convenient. ### Proposed API ```ruby Dir.foreach(path) { |name| } Dir.foreach(path) { |name, stat| } Dir.each_child(path) { |name| } Dir.each_child(path) { |name| } Dir.new(path).each_child { |name, stat| } Dir.new(path).each_child { |name, stat| } Dir.new(path).each { |name, stat| } Dir.new(path).each { |name, stat| } ``` Also important to note, the `File::Stat` is expected to be equivalent to a `lstat(2)` call, as to be able to chose to follow symlinks or not. Basic use case: ```ruby def count_ruby_files(root) count = 0 queue = [root] while dir = queue.pop Dir.(dir) do |name, stat| next if name.start_with?(".") if stat.directory? queue << File.join(dir, name) elsif stat.file? count += 1 if name.end_with?(".rb") end end end count end ``` -- https://bugs.ruby-lang.org/

5 10