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

[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

[ruby-core:124794] [Ruby Feature#19107] Allow trailing comma in method signature
by byroot (Jean Boussier) 12 Feb '26

12 Feb '26

Issue #19107 has been updated by byroot (Jean Boussier). I'm no expert on that area, but my understanding is that lambda specifically handle argument like methods do, not like proc do. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116406 * 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:124793] [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 _). Hm, not so sure about lambdas actually. Consider `|foo,|` block arguments, which causes the block to accept any number of positional arguments. I think a lambda should behave the same. If it is so, the usefulness is pretty limited since it doesn't work with the way the issue is about. Either way, I think it would need to be discussed first since I'm not 100% on the desired behaviour. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116405 * 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:123433] [Ruby Misc#21630] Suggest @Earlopain for core contributor
by kddnewton (Kevin Newton) 12 Feb '26

12 Feb '26

Issue #21630 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #21630: Suggest @Earlopain for core contributor https://bugs.ruby-lang.org/issues/21630 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- @Earlopain has been prolifically contributing to Prism for over a year, in addition to other various changes around ruby/ruby, like [96fdaf2e](https://github.com/ruby/ruby/commit/96fdaf2e393933fdd128cd1a41fa9…, [3826019f](https://github.com/ruby/ruby/commit/3826019f310991aedf0612408d7b8…, [a82e7132](https://github.com/ruby/ruby/commit/a82e7132df71bd99b5d02c0c8a348…, and [many more](https://github.com/ruby/ruby/commits/master/?author=Earlopain). I would very much like @Earlopain to be able to merge their own contributions to Ruby, since they have been of such high quality for so long. -- https://bugs.ruby-lang.org/

8 9

[ruby-core:124790] [Ruby Feature#19107] Allow trailing comma in method signature
by byroot (Jean Boussier) 12 Feb '26

12 Feb '26

Issue #19107 has been updated by byroot (Jean Boussier). They weren't mentioned, but since they use `()` like methods, I think it is implied it works for them too? ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116402 * 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:124789] [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 _). Ah, sorry. That was about lambdas, not newlines. I'll wait until the logs are published and see if they came up. They were never mentioned explicitly but it should be very easy for prism to allow them if that changes. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116401 * 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:124787] [Ruby Feature#15330] autoload_relative
by matz (Yukihiro Matsumoto) 12 Feb '26

12 Feb '26

Issue #15330 has been updated by matz (Yukihiro Matsumoto). OK, now I accept having `autoload_relative`. Matz. ---------------------------------------- Feature #15330: autoload_relative https://bugs.ruby-lang.org/issues/15330#change-116399 * Author: marcandre (Marc-Andre Lafortune) * Status: Assigned * Assignee: ioquatix (Samuel Williams) ---------------------------------------- I'd like to propose a way to autoload a constant using a relative path. It could look like: ``` autoload_relative :MyConst, 'models/my_const' ``` My proposal raises two questions: 1) what's the future of `autoload`? I believe that `autoload` has been there for years, it is used successfully and has no real alternative. I looked at a sample of 430 top gems (took the 500 top ranked according to Libraries.io, removed those that I failed to process). The number of those gems that appear to use `autoload` at least once is 94 of those (22%). The number of lines in the code where `autoload` is called can be quite big. The top 5 are: vagrant: 235 yard: 206 ffaker: 155 aws-sdk: 152 rdoc: 92 This is a minimum bound, as some gems might be using loops, my processing would only detect the one place in the code with `autoload`. 2) are many autoladed paths relative? My preliminary numbers indicate that of the 94 gems using autoload, at least 75 are autoloading some relative files. That's a lower bound, as my algorithm is pretty crude and will only count the simplest cases as being relative. An example of gem my algorithm does not detect is `yard`, because the author wrote a small method to map the relative paths to global paths (code here: https://github.com/lsegal/yard/blob/master/lib/yard/autoload.rb#L3 ) Of those where my processing detects the relative requires, a vast majority are relative. The average is that 94% of autoloaded files are relative and would benefit from `require_relative` In summary: I am convinced that `autoload` should remain in Ruby indefinitely. `autoload_relative` would actually be more useful than `autoload`. Even if the future of `autoload` remains uncertain, I would recommend adding `autoload_relative`; if it is ever decided to actually remove `autoload`, removing `autoload_relative` would not really add to the (huge) burden of gem maintainers. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124785] [Ruby Feature#21822] Expose Return Value in the ensure Block
by matz (Yukihiro Matsumoto) 12 Feb '26

12 Feb '26

Issue #21822 has been updated by matz (Yukihiro Matsumoto). I don't think it's not worth for the new syntax, where you can do similar thing with: ``` begin ret = begin # .... end ensure LOGGER.debug "return value: #{ret}" end ``` Matz. ---------------------------------------- Feature #21822: Expose Return Value in the ensure Block https://bugs.ruby-lang.org/issues/21822#change-116396 * 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