Feature #16378
closedSupport leading arguments together with ...
Description
I think this is very important, otherwise ...
can be used only very rarely.
For instance, method_missing
typically want to access the method name like:
def method_missing(name, ...)
if name.to_s.end_with?('?')
self[name]
else
fallback(name, ...)
end
end
See the original feature: https://bugs.ruby-lang.org/issues/16253#note-19.
I think most people expect def method_missing(name, ...)
to work.
Files
Updated by Eregon (Benoit Daloze) almost 5 years ago
- Related to Feature #16253: Shorthand "forward everything" syntax added
Updated by Eregon (Benoit Daloze) almost 5 years ago
- Description updated (diff)
- Target version set to 2.7
Updated by Eregon (Benoit Daloze) almost 5 years ago
Also I believe ...
could be a good way to do delegation in all versions for lexical cases (the majority):
# Could be some constant in a gem
ARGS = RUBY_VERSION < "2.7" ? "*args, &block" : "..."
class_eval <<RUBY
def method_missing(name, #{ARGS})
if name.to_s.end_with?('?')
self[name]
else
fallback(name, #{ARGS})
end
end
RUBY
And while Redmine doesn't syntax highlight <<RUBY
, at least GitHub and RubyMine do.
Updated by matz (Yukihiro Matsumoto) almost 5 years ago
- Status changed from Open to Rejected
I know trailing ...
can be very useful from C experience. But the primary purpose of Ruby ...
is method delegation. We are not going to extend the role of ...
in the language (at least for now).
Matz.
Updated by Eregon (Benoit Daloze) almost 5 years ago
matz (Yukihiro Matsumoto) wrote:
I know trailing
...
can be very useful from C experience. But the primary purpose of Ruby...
is method delegation. We are not going to extend the role of...
in the language (at least for now).
That is surprising.
It makes ...
unusable in many delegation use cases which need to extract the first(s) arguments.
The above method_missing is also delegation, isn't it?
What's your solution for that case?
Using ruby2_keywords def method_missing(name, *args)
and then having to change it to def method_missing(name, *args, **kwargs)
once ruby2_keywords
is removed?
Defining method_missing
is not something rare in Ruby. It seems a shame ...
can't be used there, even though it would a very good place to use ...
(delegation in method_missing
is almost always lexical).
BTW, R
has ...
and it supports leading arguments.
And of course the construct that ...
replaces, that is *args, &block
as "all arguments" supports leading arguments too.
Updated by Eregon (Benoit Daloze) almost 5 years ago
- Status changed from Rejected to Open
- Assignee set to matz (Yukihiro Matsumoto)
- Target version changed from 2.7 to 3.0
@matz (Yukihiro Matsumoto) Could you reply to this?
Particularly:
But the primary purpose of Ruby ... is method delegation.
Indeed, and I believe we also want to extract leading arguments in many delegation use cases.
...
not supporting leading arguments is a obvious limitation and I would think unexpected for many rubyists.
As an example, it makes ...
unusable for method_missing, which is a place where delegation often happens.
I think the decision was too quick, maybe because I set target version 2.7.
It won't be in 2.7 since that's released, but let's consider it for future releases.
Updated by Dan0042 (Daniel DeLorme) almost 5 years ago
In the DevelopersMeeting20191017Japan log there was "Future work: lead argument handling is postponed", so clearly there was the intention of adding it later.
Updated by matz (Yukihiro Matsumoto) over 4 years ago
We have found out that #method_missing
(and #send
) needed leading arguments otherwise we cannot use argument forwarding for them. I changed my mind. Accepted.
Matz.
Updated by Eregon (Benoit Daloze) over 4 years ago
- Related to Feature #16891: Restore Positional Argument to Keyword Conversion added
Updated by Eregon (Benoit Daloze) over 4 years ago
Interesting, I never saw the reply above from matz.
Looking at my email I received one but it wasn't attached to the rest of the conversation for this issue for some reason.
Great to hear it's now accepted.
I think we should have it already in 2.7.2+.
Many people clearly want it in #16891.
@jeremyevans0 (Jeremy Evans) or @nobu (Nobuyoshi Nakada) Could you implement it on master
?
Updated by Eregon (Benoit Daloze) over 4 years ago
- Related to Feature #16463: Fixing *args-delegation in Ruby 2.7: ruby2_keywords semantics by default in 2.7.1 added
Updated by jeremyevans0 (Jeremy Evans) over 4 years ago
Eregon (Benoit Daloze) wrote in #note-10:
@jeremyevans0 (Jeremy Evans) or @nobu (Nobuyoshi Nakada) Could you implement it on
master
?
I've implemented basic support, which passes make check: https://github.com/jeremyevans/ruby/commit/672901facca6f88ae40b4ea8ef59ef04efd5a5de
I think ripper support is probably broken for it, and the idFWD_KWREST sections (not currently enabled) are probably also wrong.
@nobu (Nobuyoshi Nakada), could you please fix the ripper support and idFWD_KWREST sections?
Updated by jeremyevans0 (Jeremy Evans) over 4 years ago
jeremyevans0 (Jeremy Evans) wrote in #note-12:
Eregon (Benoit Daloze) wrote in #note-10:
@jeremyevans0 (Jeremy Evans) or @nobu (Nobuyoshi Nakada) Could you implement it on
master
?I've implemented basic support, which passes make check: https://github.com/jeremyevans/ruby/commit/672901facca6f88ae40b4ea8ef59ef04efd5a5de
I think ripper support is probably broken for it, and the idFWD_KWREST sections (not currently enabled) are probably also wrong.
@nobu (Nobuyoshi Nakada), could you please fix the ripper support and idFWD_KWREST sections?
From my testing, the existing idFWD_KWREST sections for ...
without leading arguments are already broken. Defining RUBY3_KEYWORDS
in parse.y results in broken code such as args being dropped and no implicit conversion of nil into Hash (TypeError)
when using super. So I don't think there is a point trying to get idFWD_KWREST sections working for leading arguments currently. We are not going to want to switch to idFWD_KWREST sections until we drop ruby2_keywords
support, as ruby2_keywords
is significantly faster.
I updated the commit to add ripper support, and added a pull request for it: https://github.com/ruby/ruby/pull/3190
Updated by jeremyevans (Jeremy Evans) over 4 years ago
- Status changed from Open to Closed
Applied in changeset git|f8b4340fa2c254cd093ebc3bc70d2d0c46ea9997.
Add leading arguments support to arguments forwarding
The idFWD_KWREST sections may be wrong. However, the existing
idFWD_KWREST sections for ... without leading arguments are already
broken.
Implements [Feature #16378]
Updated by mame (Yusuke Endoh) over 4 years ago
@nagachika (Tomoyuki Chikanaga) Can we backport this to 2.7.2? Strictly speaking, this is a new feature, but according to public consultation about Ruby 3.0 keyword change, this seems important to mitigate the pain of the change in 2.7. Matz also agreed with the backport.
@jeremyevans0 (Jeremy Evans) If nagachika-san agreed with the backport, can you create a patch for backport?
Updated by jeremyevans0 (Jeremy Evans) over 4 years ago
mame (Yusuke Endoh) wrote in #note-15:
@jeremyevans0 (Jeremy Evans) If nagachika-san agreed with the backport, can you create a patch for backport?
Backport patch attached, in case @nagachika (Tomoyuki Chikanaga) approves.
Updated by nagachika (Tomoyuki Chikanaga) over 4 years ago
Thank you for your notice and providing the patch. I will take a look into it.
Updated by Dan0042 (Daniel DeLorme) almost 4 years ago
@nagachika (Tomoyuki Chikanaga) I would really like to see this backported to 2.7 ... may I ask for the status?
Updated by Eregon (Benoit Daloze) almost 4 years ago
Agreed it should be in 2.7 (well, I've said since the beginning of this issue :D).
Right now, I consider ...
non-existing because it's almost never usable due to the restrictions in 2.7.
Updated by nagachika (Tomoyuki Chikanaga) almost 4 years ago
Thank you for ping me. I backported f8b4340f into ruby_2_7 at 27fca66207f2c35f2f44f6a7cbbe6fd153546082.
Updated by esad (Esad Hajdarevic) 2 months ago
Is there a reason why this doesn't work with keyword arguments too?
For example:
def foo(bar:, ...)
other(...)
end
results in syntax error
Updated by jeremyevans0 (Jeremy Evans) 2 months ago
esad (Esad Hajdarevic) wrote in #note-21:
Is there a reason why this doesn't work with keyword arguments too?
For example:
def foo(bar:, ...) other(...) end
results in syntax error
Keyword arguments are not leading arguments. Trying to support what you want was not in scope. I think trying to support what you want would significantly increase the complexity, especially if you wanted to support def foo(arg, kwarg: , ...)
as well.
You should use:
def foo(*, bar:, **, &)
other(*, **, &)
end