- ruby-core - ml.ruby-lang.org

[ruby-core:125428] [Ruby Bug#22058] {Method,InstanceMethod}#super_method doesn't work correctly for refined method with refinements for method active in the caller's scope
by jeremyevans0 (Jeremy Evans) 12 Jul '26

12 Jul '26

Issue #22058 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #22058: {Method,InstanceMethod}#super_method doesn't work correctly for refined method with refinements for method active in the caller's scope https://bugs.ruby-lang.org/issues/22058 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-03T23:57:21Z master d8d2ed5dc9) +PRISM [x86_64-openbsd7.8] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I've found that Method#super_method and InstanceMethod#super_method do not work correctly in some cases for refined methods. At the least, there is a definite bug, which is that #super_method inside a scope with a refinement activated for the method results in a loop over the refined methods. I'm not sure if the semantics for #super_method for refined methods were ever discussed. Other than the bug regarding the loop over the refinement, the currently semantics seem to be: * While handling additional refined methods for the same class as the current method, #super_method will consider the refinements active at the point the method was created * For ancestors, #super_method will consider the refinements active in the scope calling #super_method These semantics seem questionable. My guess is they are not the result of intentional design, but due purely to implementation details. I see two possibilities: 1. Keep the current behavior, where results depend on refinements activated in the caller's namespace. In this case, I recommend that we not have different handling when there are other refinements for the same class as the current method should. If refinements are not in scope, #super_method should not return them. We should also consider whether #super_method should error if the receiver is a refinement method for a refinement not activated in the caller's scope. 2. Change #super_method so that it depends on the refinements activated in the namespace it was created in, for ancestors as well as for the current class. This would make #super_method return the same result no matter where it was called. I think option 2 makes more sense, but it requires that Method/InstanceMethod objects for refined methods keep a reference to the scope in which they were created. A related minor bug I found during this research is the #inspect output for #super_method results for refined methods also does not use the same format, indicating there is something internally different. Here's example code showing these issues, with commented output below: ```ruby class B def b = 16 end class A < B def b = 8 + super end module M1 refine(A){def b = 1 + super} end module M2 refine(A){def b = 2 + super} end module M3 refine(A){def b = 4 + super} end module M4 refine(B){def b = 4 + super} end I = A.new.method(:b) C = A.instance_method(:b) module N0 using M1 using M3 I = A.new.method(:b) C = A.instance_method(:b) end module N using M1 using M2 using M3 using M4 I = A.new.method(:b) C = A.instance_method(:b) puts "", "Inside module using all refinements using method created using all refinements:" p I i = I 6.times do i = i.super_method p i end puts p C c = C 6.times do c = c.super_method p c end puts "", "Inside module using all refinements using method created using some refinements:" p N0::I i = N0::I 6.times do i = i.super_method p i end puts p N0::C c = N0::C 6.times do c = c.super_method p c end puts "", "Inside module using all refinements using method created using no refinements:" p ::I i = ::I 6.times do break unless i = i.super_method p i end puts p ::C c = ::C 6.times do break unless c = c.super_method p c end end module N0 using M1 using M3 puts "", "Inside module using some refinements using method created using all refinements:" p N::I i = N::I 6.times do break unless i = i.super_method p i end puts p N::C c = N::C 6.times do break unless c = c.super_method p c end end puts "", "Top level using method created with all refinements:" p N::I i = N::I 6.times do break unless i = i.super_method p i end puts p N::C c = N::C 6.times do break unless c = c.super_method p c end puts "", "Top level using method created with some refinements:" p N0::I i = N0::I 6.times do break unless i = i.super_method p i end puts p N0::C c = N0::C 6.times do break unless c = c.super_method p c end puts "", "Top level using method created with no refinements:" p I i = I 6.times do break unless i = i.super_method p i end puts p C c = C 6.times do break unless c = c.super_method p c end ``` First, the bug. This shows a loop among active refinements. After going through M3, M2, and M1, it loops back to M3. This also shows weird #inspect output, with #super_method not showing the main class. ``` Inside module using all refinements using method created using all refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> ``` This shows the dynamic scoping of the #super_method. At time of call, only M3 and M1 are in scope. You see in the first loop, only M3 and M1 are used, but subsequent loops use M3, M2, and M1. ``` Inside module using all refinements using method created using some refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> ``` This shows a case where the Method was created with no refinements activated. Refinements for superclasses that are active in the current scope are still picked up: ``` Inside module using all refinements using method created using no refinements: #<Method: A#b() t/t43.rb:30> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: A#b() t/t43.rb:30> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> ``` More evidence for dynamic scoping. This is the opposite of the second example, where the first loop has M3, M2, and M1, and subsequent loops have M3 and M1. ``` Inside module using some refinements using method created using all refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> ``` This shows the behavior when no refinements are activated in the current scope. It still includes refinements for the same class as the current method, but no refinements for superclasses. Also, note that there is no longer a loop, because there are no refinements activated: ``` Top level using method created with all refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: A#b() t/t43.rb:30> #<Method: B#b() t/t43.rb:26> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: A#b() t/t43.rb:30> #<UnboundMethod: B#b() t/t43.rb:26> ``` This shows that only the refinements were activated at the point the method was created are included. ``` Top level using method created with some refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: A#b() t/t43.rb:30> #<Method: B#b() t/t43.rb:26> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: A#b() t/t43.rb:30> #<UnboundMethod: B#b() t/t43.rb:26> ``` This output doesn't show any problems, it shows that if refinements were not activated when the method was created, and are not activated when #super_method is called, that #super_method ignores refinements, which is what you would expect. ``` Top level using method created with no refinements: #<Method: A#b() t/t43.rb:30> #<Method: B#b() t/t43.rb:26> #<UnboundMethod: A#b() t/t43.rb:30> #<UnboundMethod: B#b() t/t43.rb:26> ``` -- https://bugs.ruby-lang.org/

4 15

[ruby-core:126055] [Ruby Feature#15222] Add a way to distinguish between Struct classes with and without keyword initializer
by Earlopain (Earlopain _) 11 Jul '26

11 Jul '26

Issue #15222 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed Added a while ago via https://bugs.ruby-lang.org/issues/18008 ---------------------------------------- Feature #15222: Add a way to distinguish between Struct classes with and without keyword initializer https://bugs.ruby-lang.org/issues/15222#change-118053 * Author: pluff (Pavel Shutsin) * Status: Closed ---------------------------------------- With Ruby 2.5.0 Struct subclasses can have different `initialize` arguments list based on `keyword_init` option. However, there is no way in Ruby to distinguish Structs with keyword arguments syntax and without. I propose a class method `keyword_init?` that will allow developers to understand if given structure has keyword based initializer or not. Example use case for serialization: ``` Foo = Struct.new(:foo, keyword_init: true) Bar = Struct.new(:bar) def dump_and_load_struct(object) serialized = object.to_h object.class.new(object.class.keyword_init? ? serialized : serialized.values) end dump_and_load_struct(Foo.new(foo: 1)) # #<struct Foo foo=1> dump_and_load_struct(Bar.new(2)) # #<struct Bar bar=1> ``` An issue that might be related: https://bugs.ruby-lang.org/issues/14314 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126054] [Ruby Feature#10949] Time is WB unprotected
by Earlopain (Earlopain _) 11 Jul '26

11 Jul '26

Issue #10949 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed It's WB protected since https://github.com/ruby/ruby/commit/1c0127ed5e1aaf1386e2176e499d4cb25d171a21 ---------------------------------------- Feature #10949: Time is WB unprotected https://bugs.ruby-lang.org/issues/10949#change-118050 * Author: sylvain.joyeux (Sylvain Joyeux) * Status: Closed ---------------------------------------- Ruby's built-in Time object is shady. Unfortunately, it is an object that can commonly be created in big numbers (think logs or stuff like that), and since they don't store relationship with other objects they are perfect candidate for the oldgen. I don't really know if there is a kind of policy about which built-in Ruby objects should be sunny or not, so I just put this as a feature request (as opposed to having it as a bug) -- https://bugs.ruby-lang.org/

1 0

[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