[ruby-core:96511] [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 Eregon (Benoit Daloze).


I think it should be:
```ruby
[[:rest, :*], [:keyrest, :**], [:block, :&]]
```

because that's what it will act like in Ruby 3.0+.

Is there an advantage to have its own type of parameter?
That would make usages of `#parameters` more complex for I think very little gain.


----------------------------------------
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-83444

* Author: aaronc81 (Aaron Christiansen)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
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:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>