Project

General

Profile

Feature #16378

Support leading arguments together with ...

Added by Eregon (Benoit Daloze) 3 months ago. Updated about 2 months ago.

Status:
Open
Priority:
Normal
Target version:
[ruby-core:95993]

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.


Related issues

Related to Ruby master - Feature #16253: Shorthand "forward everything" syntaxClosedActions
#1

Updated by Eregon (Benoit Daloze) 3 months ago

  • Related to Feature #16253: Shorthand "forward everything" syntax added
#2

Updated by Eregon (Benoit Daloze) 3 months ago

  • Target version set to 2.7
  • Description updated (diff)

Updated by Eregon (Benoit Daloze) 3 months 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) 3 months 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) 3 months 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) about 2 months ago

  • Target version changed from 2.7 to 3.0
  • Assignee set to matz (Yukihiro Matsumoto)
  • Status changed from Rejected to Open

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) about 2 months ago

In the DevelopersMeeting20191017Japan log there was "Future work: lead argument handling is postponed", so clearly there was the intention of adding it later.

Also available in: Atom PDF