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

[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: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

[ruby-core:124805] [Ruby Feature#14737] Split default gems into separate directory structure
by hsbt (Hiroshi SHIBATA) 12 Feb '26

12 Feb '26

Issue #14737 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Rejected I have no plan to apply this proposal. I understand that the current situation is not optimal, but there is no advantage to change it considering that this structure has been in use for eight years with no critical issues. ---------------------------------------- Feature #14737: Split default gems into separate directory structure https://bugs.ruby-lang.org/issues/14737#change-116422 * Author: vo.x (Vit Ondruch) * Status: Rejected * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- On Fedora, we are using operating_system.rb [1], [2] to setup various RubyGems paths. Unfortunately, if we change Gem.default_dir (which we want to point into user home directory on Fedora), then this also changes location for default gems (!!), which are later not discovered by RubyGems [3]. It was not been a big deal for use, since we used to unbundle the gems shipped in Ruby, but with the gemification of StdLib, unbundlig becomes unsustainable (it is more work, but mainly it is incompatible change). To fix this issue, I modified the operating_system.rb to behave similarly to what Arch does [4], i.e. we started to inject "--user-install" option [1]. Unfortunately, this revealed the RubyGems are not respecting their own interfaces and I had to fix at least one of them along the way to make it work [6]. Apparently, using the "--user-install" option itself has some drawbacks and what is worse, it is not respected by Bundler, which was recently pointed out [5]. When I was fixing RubyGems [6], I just realized how the default gems are hacked up and how much is the original RubyGems configurability broken by this. This leads me to the proposal: **Could we please install default gems into different directory then the other, user installed, gems?** Since RubyGems were always designed to support various gem directory structures, the directory structure for default gems would become just other directory directory structure and would not collide with overrides in operating_system.rb, letting the distributions to override what was always designed to be overridable. BTW I believe that one nice side effect of this change would be simplification of RubyGems code base. The default gems would live in "default_gems" directory, their .gemspec files could be in standard "default_gems/specifications" directory and we could forget about "default_gems/specifications/defaults", etc. BTW2 I could fill this against RubyGems, but the default gems are Ruby stuff IMO, so I think this is appropriate tracker. [1]: https://src.fedoraproject.org/rpms/ruby/blob/master/f/operating_system.rb [2]: https://src.fedoraproject.org/rpms/ruby/blob/f27/f/operating_system.rb [3]: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.… [4]: https://wiki.archlinux.org/index.php/ruby [5]: https://bugzilla.redhat.com/show_bug.cgi?id=1574594 [6]: https://github.com/rubygems/rubygems/pull/2116 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124803] [Ruby Feature#21822] Expose Return Value in the ensure Block
by artemb (Artem Borodkin) 12 Feb '26

12 Feb '26

Issue #21822 has been updated by artemb (Artem Borodkin). > ``` > begin > ret = begin > # .... > end > ensure > LOGGER.debug "return value: #{ret}" > end > ``` For me, ensure => ret looks cleaner, reduces cognitive overhead, and is simply easier on the eyes when reviewing real code. The structure is easier to parse visually, and the intent is clearer compared to the alternatives. Also, it doesn’t break any existing behavior — it’s purely additive, just a small but useful extension that makes the code more elegant and pleasant to read. ---------------------------------------- Feature #21822: Expose Return Value in the ensure Block https://bugs.ruby-lang.org/issues/21822#change-116419 * Author: artemb (Artem Borodkin) * Status: Open ---------------------------------------- I'd like to propose a simple feature that allows easy access to the return value inside an ensure block. ```ruby begin # ... ensure => ret # ret is nil if an exception is raised LOGGER.debug "return value: #{ret}" end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124684] [Ruby Feature#21863] Add RBASIC_FLAGS() and RBASIC_SET_FLAGS()
by Eregon (Benoit Daloze) 12 Feb '26

12 Feb '26

Issue #21863 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21863: Add RBASIC_FLAGS() and RBASIC_SET_FLAGS() https://bugs.ruby-lang.org/issues/21863 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- Currently there is `RBASIC_CLASS()` which is the same as `RBASIC(obj)->klass` on CRuby but also checks it's called on a valid object: https://github.com/ruby/ruby/blob/86dba8cfaeabb3b86df921da24b3243b9ce4ab2a/… I would like to add `RBASIC_FLAGS()` and `RBASIC_SET_FLAGS()`, which could be defined like this on CRuby: ```c #define RBASIC_FLAGS(obj) (RBASIC(obj)->flags) #define RBASIC_SET_FLAGS(obj, flags_to_set) (RBASIC(obj)->flags = flags_to_set) ``` This would let native extensions access those flags without relying on the specific fields, layout and existence of a `RBasic` `struct`. My main motivation here is that TruffleRuby, the alternative Ruby implementation with the most complete native extension support, cannot support having mutable fields in `RBasic`. The reason is because flags are mutable, it would be impossible to find out when the user writes to the flags if they write with just `RBASIC(obj)->flags = v`. And since the state related to flags is held internally on the Java object, writing to native memory would do nothing, which would be incompatible. With these macros we can know when the user writes to the flags and update the internal representation. In fact, TruffleRuby already implements these macros, since [this comment](https://github.com/truffleruby/truffleruby/issues/3118#issuecommen…. I would like to make it a standard C API to increase adoption and make it easier to discover. This would also be useful on CRuby to do additional checks when reading and writing flags: * We could add `RBIMPL_ASSERT_OR_ASSUME(!RB_SPECIAL_CONST_P(obj));` like `RBASIC_CLASS` does. * We could check that the frozen flag is not removed. * We could check that the frozen flag is consistent with the frozen flag on the object shape (if CRuby has a frozen flag in the shape). * We could check that the shape is not changed by native extensions this way (since the shape is stored in flags on 64-bit machines). * CRuby would be able to evolve the representation of RBasic more freely in the future. I'll note that there are already some macros/functions to manipulate flags such as `RB_FL_TEST()`, however they don't allow just reading or writing the flags: https://github.com/ruby/ruby/blob/86dba8cfaeabb3b86df921da24b3243b9ce4ab2a/… However it seems clear that C extensions do read and write the RBasic->flags field currently and these `RB_FL_*()` macros/functions are not enough, so `RBASIC_FLAGS()` and `RBASIC_SET_FLAGS()` would be obvious replacements. Here is a gem-codesearch for `/RBASIC\(.+\)->flags/`: https://gist.github.com/eregon/5866bd86e626ae723b5b16d935af8f94 An alternative would be to deprecate the RBasic->flags field entirely and eventually hide it, and don't provide a replacement for direct reading/writing flags, but that would break a bunch of native extensions, so it does not seem actionable. With this proposal we won't break anything and we'll actually get finer control over accesses to flags if e.g. we want to prevent some invariant-breaking changes. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:124800] [Ruby Misc#21825] Status of the universal parser implementing the Prism API
by Eregon (Benoit Daloze) 12 Feb '26

12 Feb '26

Issue #21825 has been updated by Eregon (Benoit Daloze). What does "Rejected" means in this case? No plan to do this? Does that mean Universal Parser no longer has the intention to become the Ruby parser used by everything? Having to maintain both parsers and both bytecode compilers is not an overhead we can ignore forever. ---------------------------------------- Misc #21825: Status of the universal parser implementing the Prism API https://bugs.ruby-lang.org/issues/21825#change-116414 * Author: Eregon (Benoit Daloze) * Status: Rejected ---------------------------------------- I'm opening this issue to discuss and ask the status of the universal parser implementing the Prism API. [Matz has agreed that going forward the official parser API for Ruby will be the Prism API](https://railsatscale.com/2024-04-16-prism-in-2024/), therefore if `parse.y` wants to remain a longer-term possibility it will have to somehow implement the Prism API. (this is not new, I recall discussing this at RubyKaigi 2024 with matz and @yui-knk) The Prism API covers clearly at least the Ruby API `Prism::Node`. But also if the universal parser is a complete alternative for Prism (if not it wouldn't really be *universal* and lots of existing Prism usages couldn't switch to it), it would need to also support the Java, JavaScript and Rust APIs of Prism. And also the AST part of the C API of Prism too. I think the most sensible and maybe the only realistic way is for `parse.y` to generate a Prism C AST using the AST structs from Prism: https://github.com/eregon/prism-generated/blob/generated/include/prism/ast.h such as `struct pm_call_node`. That way, all the higher-level APIs and code in the prism gem can be reused as-is and the only real difference is whether using the [prism.c](https://github.com/ruby/prism/blob/main/src/prism.c) parser or the `parse.y` parser, but the output would be the exact same. When that happens it would actually become possible to just switch the parser with `--parser=`, vs currently switching the CRuby source-to-bytecode compiler as well. IOW, there would be no need for the massive duplication in `compile.c` and `prism_compile.c`, we'd keep only `prism_compile.c` (and probably rename it), since `parse.y` would also generated a Prism C AST. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124798] [Ruby Feature#19107] Allow trailing comma in method signature
by Earlopain (Earlopain _) 12 Feb '26

12 Feb '26

Issue #19107 has been updated by Earlopain (Earlopain _). https://github.com/ruby/prism/pull/3920 for the prism implementation. I plan to add https://bugs.ruby-lang.org/issues/21875 to the next devmeeting. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116411 * Author: byroot (Jean Boussier) * Status: Open * Assignee: prism ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124795] [Ruby Feature#19107] Allow trailing comma in method signature
by Earlopain (Earlopain _) 12 Feb '26

12 Feb '26

Issue #19107 has been updated by Earlopain (Earlopain _). `->(...) {}` is syntax invalid, same as `foo do |...|; end`, in that regard they are more like blocks. Lambdas do check arity though, which is probably what you were talking about. I'll make a separate issue for this to understand what the desired behavior should be if that's ok. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116407 * Author: byroot (Jean Boussier) * Status: Open * Assignee: prism ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0