[ruby-core:97245] [Ruby master Feature#16456] Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters

Issue #16456 has been updated by connorshea (Connor Shea).


I'd definitely like to see this as well. It'd be useful for Sorbet since it uses the parameters method to reconstruct methods when generating scaffolds for gem methods and other Ruby code.

https://github.com/sorbet/sorbet/blob/29a967a22cc8cfcccb3d6a502b9ccb99cace0f5c/gems/sorbet/lib/gem-generator-tracepoint/tracepoint_serializer.rb#L186-L206

----------------------------------------
Feature #16456: Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters
https://bugs.ruby-lang.org/issues/16456#change-84357

* Author: aaronc81 (Aaron Christiansen)
* Status: Open
* Priority: Normal
----------------------------------------
A method defined with `...` as its parameter list is equivalent to one defined with `*args, &blk`, according to `Method#parameters`.

```ruby
def foo(...); end
p method(:foo).parameters
# => [[:rest, :*], [:block, :&]]
```

Even in Ruby 2.7, `...` and `*args, &blk` are not *quite* equivalent as the latter may produce a warning where the former does not. In Ruby 3.0 and beyond, `...` and `*args, &blk` will have a substantial semantic difference. Due to this, I don't consider the current behaviour of `Method#parameters` particularly ideal when dealing with methods using this new syntax.

If the goal of `...` is to be a "delegate everything" operator, even when parameter passing is changed like in Ruby 3.0, I would propose that `Method#parameters` considers it a unique type of parameter. For example:

```ruby
def foo(...); end
p method(:foo).parameters
# => [[:delegate, :"..."]]
```



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>