December 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:115629] [Ruby master Feature#18980] Re-reconsider numbered parameters: `it` as a default block parameter
by k0kubun (Takashi Kokubun) 06 Dec '23

06 Dec '23

Issue #18980 has been updated by k0kubun (Takashi Kokubun). Description updated Status changed from Open to Assigned Assignee set to k0kubun (Takashi Kokubun) Target version set to 3.4 In today's Developers Meeting, @matz accepted to warn `it` in Ruby 3.3 and add `it` in Ruby 3.4. Quote from the meeting notes: > * matz: accept `it` on Ruby 3.4. > * ruby 3.3 will warn and ruby 3.4 will use the new semantics I also copied the discussed specification to the ticket description. In Ruby 3.3, `it` should be warned only when `it` will behave like `_1` in Ruby 3.4. ---------------------------------------- Feature #18980: Re-reconsider numbered parameters: `it` as a default block parameter https://bugs.ruby-lang.org/issues/18980#change-105563 * Author: k0kubun (Takashi Kokubun) * Status: Assigned * Priority: Normal * Assignee: k0kubun (Takashi Kokubun) * Target version: 3.4 ---------------------------------------- ## Problem Numbered parameters (`_1`, `_2`, ...) look like unused local variables and I don't feel motivated to use them, even though I need this feature very often and always come up with `_1`. ```rb [1, 2, 3].each { puts _1 } ``` I have barely used it in the last 2~3 years because it looks like a compromised syntax. I even hesitate to use it on IRB. <details> <summary>Why I don't use <code>_1</code></summary> I'm not clever enough to remember the order of parameters. Therefore, when a block has multiple parameters, I'd always want to name those parameters because which is `_1` or `_2` is not immediately obvious. Thus I would use this feature only when a block takes a single argument, which is actually pretty common. If I use `_1`, it feels like there might be a second argument, and you might waste time to think about `_2`, even if `_2` doesn't exist, which is a cognitive overhead. If you use `it`, it kinda implies there's only a single argument, so you don't need to spend time remembering whether `_2` exists or not. It is important for me that there's no number in `it`. </details> ## Proposal * Ruby 3.3: Warn `it` method calls without a receiver, arguments, or a block. * Ruby 3.4: Introduce `it` as follows. ### Specification ```rb [1, 2, 3].each { puts it } ``` `it`s behavior should be as close to `_1` as possible. `it` should treat array arguments in the same way as `_1`. `it` doesn't work in a block when an ordinary parameter is defined. `it` is implemented as a special case of `getlocal` insn, not a method. `it` without an argument is considered `_1` or a normal local variable if defined. `it` is considered a method call only when it has any positional/keyword/block arguments. <details> <summary>Full specification</summary> ```ruby # Ruby 3.4 def foo it #=> method call _1 #=> method call 1.times do p it #=> 0 it = "foo" p it #=> "foo" p _1 #=> 0 _1 = "foo" # Syntax Error p _1 #=> N/A p foo #=> method call foo = 1 p foo #=> local var it "foo" do # method call (rspec) end end 1.times do || p _1 # Syntax Error it # method call end 1.times do ["Foo"].any? {|| it } # method call end yield_1_and_2 do # yield 1, 2 p _1 #=> 1 p it #=> 1 end yield_ary do # yield [1, 2] p _1 #=> [1, 2] p it #=> [1, 2] end 1.times do p [_1, it] # Syntax Error p [_2, it] # Syntax Error end end ``` </details> ## Past discussions * [Feature #4475] default variable name for parameter: Proposed `it`, and merged as `@1`. * 2019/03/13: [DevelopersMeeting20190311Japan](https://docs.google.com/document/d/e/2PACX-… * 2019/04/17: [DevelopersMeeting20190417Japan](https://docs.google.com/document/d/1hw6Xca8… * 2019/04/20: [Ruby Committers vs the World](https://youtu.be/5eAXAUTtNYU?t=3118) * [Feature #15723] Reconsider numbered parameters: Renamed `@1` to `_1`. * 2019/08/29: [DevelopersMeeting20190829Japan](https://docs.google.com/document/d/1XypDO1c… * [Feature #15897] `it` as a default block parameter: Proposed `it`, and got closed because `_1` was merged. * [Feature #18980] Re-reconsider numbered parameters: (this ticket) * 2022/09/08: [Ruby Committers vs the World](https://youtu.be/ajm3lr6Y9yE?si=yyWGiZHoUWqZiTaS&t=2920) ### Compatibility `it` has not necessarily been rejected by Matz; he just said [it's difficult to keep compatibility](https://bugs.ruby-lang.org/issues/4475#note-6) and [`it` or `this` _could_ break existing code](https://bugs.ruby-lang.org/issues/15723#note-2). It feels like everybody thinks `it` is the most beautiful option but is not sure if `it` breaks compatibility. But, in reality, does `it`? The following cases have been discussed: * `it` method, most famously in RSpec: You almost always pass a positional and/or block argument to RSpec's `it`, so the conflict is avoided with my proposal. You virtually never use a completely naked `it` ([comment](https://bugs.ruby-lang.org/issues/15897#note-29)) * `it` local variable: With the specification in my proposal, the existing code can continue to work if we consider `it` as a local variable when defined. With the specification in my proposal, existing code seems to break if and only if you call a method `#it` without an argument. But it seems pretty rare (reminder: a block given to an RSpec test case is also an argument). It almost feels like people are too afraid of compatibility problems that barely exist or have not really thought about options to address them. Also, you could always experiment with just showing warnings, which doesn't break any compatibility. Even if it takes 2~3 years of a warning period, I'd be happy to use that in 3 years. ### Confusion We should separately discuss incompatible cases and "works but confusing" cases. Potential confusion points: * RSpec's `it "tests something" do ... end` vs `it` inside the `do ... end` * `it` could be a local variable or `_1`, depending on the situation My two cents: You'd rarely need to write `it` directly under RSpec's `it` block, and you would just name a block argument for that case. In a nested block under a test case, I don't think you'd feel `it` is RSpec's. When you use a local variable `it = 1`, you'd use the local variable in a very small scope or few lines because otherwise, it'd be very hard to figure out what the local variable has anyway. So you'd likely see the assignment `it = 1` near the use of the local variable and you could easily notice `it` is not `_1`. If not, such code would be confusing and fragile even without this feature. The same applies when `it` is a method/block argument. I believe it wouldn't be as confusing as some people think, and you can always choose to not use `it` in places where `it` is confusing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115628] [Ruby master Feature#11322] OpenUri: RuntimeError: HTTP redirection loop
by hsbt (Hiroshi SHIBATA) 06 Dec '23

06 Dec '23

Issue #11322 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed I merged https://github.com/ruby/open-uri/pull/18. Thanks all. ---------------------------------------- Feature #11322: OpenUri: RuntimeError: HTTP redirection loop https://bugs.ruby-lang.org/issues/11322#change-105562 * Author: tbsprs (Tobias Preuss) * Status: Closed * Priority: Normal * Assignee: akr (Akira Tanaka) ---------------------------------------- Trying to download [this file](http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.zip) from [this website](http://www.london.ca/city-hall/open-data/Pages/Open-Data-Data-Catalogue.aspx) with [`OpenUri`](http://ruby-doc.org/stdlib-2.2.2/libdoc/open-uri/rdoc/OpenURI.html) fails with the runtime error "HTTP redirection loop". Here is how I can reproduce the error: ~~~ > require 'open-uri' => true > open('http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.…') RuntimeError: HTTP redirection loop: http://apps.london.ca/uniquesig87fdc01fb86ce6f0fd235c713015d7d7/uniquesig0/… from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:232:in `open_loop' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:150:in `open_uri' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:716:in `open' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:34:in `open' from (irb):2 from /home/john/.rvm/rubies/ruby-2.2.2/bin/irb:11:in `<main>' ~~~ ---Files-------------------------------- open_uri-redirect-cookie-11322.patch (2.3 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115627] [Ruby master Feature#11322] OpenUri: RuntimeError: HTTP redirection loop
by akr (Akira Tanaka) 06 Dec '23

06 Dec '23

Issue #11322 has been updated by akr (Akira Tanaka). I agree with `max_redirects` option. ---------------------------------------- Feature #11322: OpenUri: RuntimeError: HTTP redirection loop https://bugs.ruby-lang.org/issues/11322#change-105561 * Author: tbsprs (Tobias Preuss) * Status: Assigned * Priority: Normal * Assignee: akr (Akira Tanaka) ---------------------------------------- Trying to download [this file](http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.zip) from [this website](http://www.london.ca/city-hall/open-data/Pages/Open-Data-Data-Catalogue.aspx) with [`OpenUri`](http://ruby-doc.org/stdlib-2.2.2/libdoc/open-uri/rdoc/OpenURI.html) fails with the runtime error "HTTP redirection loop". Here is how I can reproduce the error: ~~~ > require 'open-uri' => true > open('http://apps.london.ca/OpenData/ShapeFiles_Zipped/2010_skateboard_parks_shp.…') RuntimeError: HTTP redirection loop: http://apps.london.ca/uniquesig87fdc01fb86ce6f0fd235c713015d7d7/uniquesig0/… from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:232:in `open_loop' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:150:in `open_uri' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:716:in `open' from /home/john/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/open-uri.rb:34:in `open' from (irb):2 from /home/john/.rvm/rubies/ruby-2.2.2/bin/irb:11:in `<main>' ~~~ ---Files-------------------------------- open_uri-redirect-cookie-11322.patch (2.3 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115428] [Ruby master Feature#20011] Reduce implicit array allocations on caller side of method calling
by jeremyevans0 (Jeremy Evans) 06 Dec '23

06 Dec '23

Issue #20011 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #20011: Reduce implicit array allocations on caller side of method calling https://bugs.ruby-lang.org/issues/20011 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal ---------------------------------------- I would like to use the peephole optimizer to eliminate caller-side array allocations for the following cases, by switching `splatarray true` to `splatarray false`: ```ruby f(1, *a) f(1, *a, &lvar) f(1, *a, &@ivar) f(*a, **lvar) f(*a, **@ivar) f(*a, **lvar, &lvar) f(*a, **@ivar, &@ivar) f(*a, kw: 1) f(*a, kw:1, &lvar) f(*a, kw:1, &@ivar) ``` In terms of safety, currently, `f(*a, &lvar)` and `f(*a, &@ivar)` both avoid array allocations (`splatarray false`), and all of the above are as safe as those in terms of safety. Note that since at least Ruby 1.8, in pathlogical cases, `lvar.to_proc` can modify `a`, which results in behavior contrary to expected evaluation order: ```ruby ary = [1,2] kwd = Object.new kwd.define_singleton_method(:to_proc) {ary << 4; lambda{}} p(*ary, &kwd) # 4 included in output ``` I think that for both the current `f(*a, &lvar)` and `f(*a, &@ivar)` cases and all of the above cases, the benefit of avoiding the allocation is higher than the costs, considering that only pathologic cases fail. If we do not want the above optimization, for consistency, we should remove the optimization of `f(*a, &lvar)` and `f(*a, &@ivar)` (or update the optimization so that it is only used if `lvar` or `@ivar` is already a proc), which will slow Ruby down. I have submitted a pull request for these changes: https://github.com/ruby/ruby/pull/8853 To make sure these cases are worth optimizing, I did some analysis: For ruby -e '' (just loads rubygems): ``` 5 : f(1, *a) 2 : f(1, *a, &lvar) | f(1, *a, &@ivar) ``` Current stdlib: ``` 139 : f(1, *a) 3 : f(1, *a, &lvar) | f(1, *a, &@ivar) 4 : f(*a, **lvar) | f(*a, **@ivar) ``` Rails master: ``` 77 : f(1, *a) 5 : f(1, *a, &lvar) | f(1, *a, &@ivar) 26 : f(*a, **lvar) | f(*a, **@ivar) 5 : f(*a, kw: 1) ``` minitest 5.20 (bundled gem): ``` 4 : f(1, *a) 1 : f(1, *a, &lvar) | f(1, *a, &@ivar) 2 : f(*a, **lvar) | f(*a, **@ivar) 2 : f(*a, **lvar, &lvar) | f(*a, **@ivar, &@ivar) ``` capybara 3.39.2: ``` 15 : f(1, *a) 2 : f(1, *a, &lvar) | f(1, *a, &@ivar) 19 : f(*a, **lvar) | f(*a, **@ivar) 4 : f(*a, **lvar, &lvar) | f(*a, **@ivar, &@ivar) ``` This shows that all cases optimized except `f(*a, kw:1, &lvar)` and `f(*a, kw:1, &@ivar)` are used in common gems. Those cases could be removed if people think they are not worth optimizing. Code backing the above analysis can be found at https://github.com/ruby/ruby/pull/8853#issuecomment-1817656139 -- https://bugs.ruby-lang.org/

3 7

[ruby-core:115625] [Ruby master Bug#18886] Struct aref and aset don't trigger any tracepoints.
by ko1 (Koichi Sasada) 06 Dec '23

06 Dec '23

Issue #18886 has been updated by ko1 (Koichi Sasada). Please merge it. > I don't think this will affect performance unless TracePoint is used, because the same method caching is done in both cases. Showing benchmarking result will help IMO to confirm there is no penalty. ---------------------------------------- Bug #18886: Struct aref and aset don't trigger any tracepoints. https://bugs.ruby-lang.org/issues/18886#change-105557 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Given the following program, `thing.name` and `thing.shape` don't trigger `c_call` trace points (or any trace points actually). ```ruby pp RUBY_VERSION trace_point = TracePoint.new(:line, :call, :c_call, :a_call) do |trace| puts trace.event if trace.event == :call # Ruby doesn't always mark call-sites in sub-expressions, so we use this approach to compute a call site and mark it: if location = caller_locations(2, 1).first and path = location.path puts "> #{path}:#{location.lineno}:#{trace.event}" end end if path = trace.path puts "= #{path}:#{trace.lineno}:#{trace.event}" end end trace_point.enable # This will trigger call trace points class Thing def name :cat end def shape :square end end thing = Thing.new # Thing = Struct.new(:name, :shape) # thing = Thing.new(:cat, :rectangle) [ name: thing.name, shape: thing.shape, ] ``` ## Current HEAD ``` = ../test.rb:30:line: = ../test.rb:30:c_call:new = ../test.rb:30:c_call:inherited = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:const_added = ../test.rb:31:line: = ../test.rb:31:c_call:new = ../test.rb:31:c_call:initialize = ../test.rb:34:line: ``` ## Proposed PR ``` = ../test.rb:30:line: = ../test.rb:30:c_call:new = ../test.rb:30:c_call:inherited = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:const_added = ../test.rb:31:line: = ../test.rb:31:c_call:new = ../test.rb:31:c_call:initialize = ../test.rb:34:line: = ../test.rb:34:c_call:name = ../test.rb:35:c_call:shape ``` The reason is the internal implementation of struct doesn't have trace point instrumentation in `vm_call_opt_struct_aset` or `vm_call_opt_struct_aref`. Proposed fix: https://github.com/ruby/ruby/pull/6071 but this would need a review, maybe @jeremyevans0 and @ko1 can help. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115388] [Ruby master Feature#20005] Add C API to return symbols of native extensions resolved from features
by tagomoris (Satoshi Tagomori) 06 Dec '23

06 Dec '23

Issue #20005 has been reported by tagomoris (Satoshi Tagomori). ---------------------------------------- Feature #20005: Add C API to return symbols of native extensions resolved from features https://bugs.ruby-lang.org/issues/20005 * Author: tagomoris (Satoshi Tagomori) * Status: Open * Priority: Normal ---------------------------------------- I want an API to resolve symbols of other native extensions by a feature name and a symbol name (just like `dlsym`). (`rb_dln_resolve_symbol` is an example function name of this feature in the example below) ```c // "a_client_open" is a function defined in "/..../a_client.so", that should be loaded in Ruby beforehand. // in the extension to be "a.so" VALUE (*a_client_open)(VALUE); void Init_a(void) { a_client_open = (VALUE(*)(VALUE))rb_dln_resolve_symbol("a_client", "a_client_open"); // the return value may be NULL if the symbols is not found } ``` This API is to replace direct reference of external symbols. Currently, native extensions have to just call the function of other extensions directly on the assumption of: * The dependency native extension is already loaded * The symbol is defined correctly in the dependency (the version of dependency is correct&expected) Otherwise, it crashes. This API provides a way for developers to raise exceptions if the resolved symbol is `NULL`, and these exceptions can display meaningful messages and instructions to the users of extensions. -- https://bugs.ruby-lang.org/

4 13

[ruby-core:115619] [Ruby master Feature#16431] Optionally load did_you_mean (and RubyGems)
by hsbt (Hiroshi SHIBATA) 06 Dec '23

06 Dec '23

Issue #16431 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed https://github.com/ruby/ruby/pull/2764 has been merged. ---------------------------------------- Feature #16431: Optionally load did_you_mean (and RubyGems) https://bugs.ruby-lang.org/issues/16431#change-105551 * Author: vo.x (Vit Ondruch) * Status: Closed * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I just have opened PR [1], which allows Ruby to run when did_you_mean is not available. As I previously discussed in #16427, there are cases when speed, memory, disk or network bandwidth is a concern and did_you_mean is not useful for runtime. This is especially useful when Ruby is installed via packaging systems of (Linux) distributions. The PR is split into 4 commits, because since I was there, I prepared similar changes to RubyGems. [1]: https://github.com/ruby/ruby/pull/2764 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115304] [Ruby master Feature#19993] Optionally Free all memory at exit
by HParker (Adam Hess) 06 Dec '23

06 Dec '23

Issue #19993 has been reported by HParker (Adam Hess). ---------------------------------------- Feature #19993: Optionally Free all memory at exit https://bugs.ruby-lang.org/issues/19993 * Author: HParker (Adam Hess) * Status: Open * Priority: Normal ---------------------------------------- Add a runtime option allowing Ruby to optionally free all memory at shutdown. # why Today, memory sanitizers are difficult to use with Ruby, since not all memory is freed at shutdown. it is difficult to detect memory leaks or errors in Ruby or in Ruby C extensions when these tools are not available. While implementing this feature, we were able to identify and fix a number of memory leaks and errors. https://github.com/ruby/ruby/pull/8556 https://github.com/ruby/ruby/pull/8512 https://github.com/ruby/ruby/pull/8503 https://github.com/ruby/ruby/pull/8487 https://github.com/ruby/ruby/pull/8452 https://github.com/ruby/ruby/pull/8501 https://github.com/ruby/ruby/pull/8481 https://github.com/ruby/ruby/pull/8555 This shows that having access to tools like this can make finding and fixing memory bugs easier. # current progress Today we can allow ruby developers to enable freeing memory at shutdown via the `free-at-shutdown` runtime option. PR: https://github.com/ruby/ruby/pull/8868 running, without `--free-on-shutdown`: ``` valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes -- ./miniruby basictest/test.rb ``` ``` ==573270== LEAK SUMMARY: ==573270== definitely lost: 658,324 bytes in 5,387 blocks ==573270== indirectly lost: 955,708 bytes in 11,957 blocks ==573270== possibly lost: 2,071,096 bytes in 12 blocks ==573270== still reachable: 161,881 bytes in 275 blocks ==573270== suppressed: 0 bytes in 0 blocks ==573270== Reachable blocks (those to which a pointer was found) are not shown. ==573270== To see them, rerun with: --leak-check=full --show-leak-kinds=all ``` with `--free-on-shutdown` ``` valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes -- ./miniruby --free-on-shutdown basictest/test.rb ``` ``` ==573306== HEAP SUMMARY: ==573306== in use at exit: 0 bytes in 0 blocks ==573306== total heap usage: 43,643 allocs, 43,643 frees, 29,222,534 bytes allocated ==573306== ==573306== All heap blocks were freed -- no leaks are possible ``` # future plans * Continue improving memory safety * add `valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes -- ./miniruby --free-on-shutdown basictest/test.rb` to CI * Allow C extensions to do a "optional destruct for memory safety" so they can leverage the same memory sanitizer tools. -- https://bugs.ruby-lang.org/

4 7

[ruby-core:115333] [Ruby master Misc#19997] DevMeeting-2023-11-30
by mame (Yusuke Endoh) 06 Dec '23

06 Dec '23

Issue #19997 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #19997: DevMeeting-2023-11-30 https://bugs.ruby-lang.org/issues/19997 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2023/11/30 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2023/11/27. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

10 14

[ruby-core:115593] [Ruby master Bug#20041] Array destructuring and default values in parameters
by tenderlovemaking (Aaron Patterson) 06 Dec '23

06 Dec '23

Issue #20041 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #20041: Array destructuring and default values in parameters https://bugs.ruby-lang.org/issues/20041 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- It's possible to set the default value of a parameter to a previous parameter. For example: ```ruby def foo(a, b = a) b end foo([1, 2]) # => [1, 2] ``` However, if the parameters are destructured, the destructring happens _after_ default parameter assignment. For example: ```ruby def foo((x, y), b = x) [x, y, b] end foo([1, 2]) # => [1, 2, nil] ``` Is this expected behavior? I would have expected the parameters to be "evaluated" from left to right, and the array destructuring to happen _before_ the default parameter assignment. Thanks! -- https://bugs.ruby-lang.org/

2 3