ml.ruby-lang.org
Sign In Sign Up
Manage this list Sign In Sign Up

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

ruby-core

Thread Start a new thread
Download
Threads by month
  • ----- 2026 -----
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
ruby-core@ml.ruby-lang.org

February 2026

  • 2 participants
  • 173 discussions
[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
0 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
0 0
[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
0 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
0 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
0 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
0 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
0 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
0 0
[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
0 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
0 0
  • ← Newer
  • 1
  • ...
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • Older →

HyperKitty Powered by HyperKitty version 1.3.12.