Feature #16379: Backporting ... to Ruby 2.4 - 2.6 and pass_keywords

• Status: Closed
• Assignee: -
• Target version: -

[Eregon (Benoit Daloze)]

I've heard quite a few people saying that backporting ... to Ruby 2.4-2.6 would be a good way to do migration for keyword arguments.
In fact, if we have ... in Ruby 2.4+, I think ... could be the way to do 90%+ of delegation in a backward-compatible way, and would be vastly more elegant than a hidden Hash flag (ruby2_keywords).

What does the Ruby core team think about that?

I think ... works nicely for lexical delegation:

def delegate(...)
  target(...)
end

It can also work for delegating in a separate method by using ... inside a block inside the method accepting ...:
https://eregon.me/blog/2019/11/10/the-delegation-challenge-of-ruby27.html#pass_keywords

def initialize(...)
  @call_later = -> { target(...) }
end

def call
  @call_later.call
end

---

If we don't want to backport ..., there is also the option to use pass_keywords like so:

pass_keywords def delegate(*args, &block)
  target(*args, &block)
end

pass_keywords def initialize(*args, &block)
  @call_later = -> { target(*args, &block) }
end

def call
  @call_later.call
end

Which can easily work by making pass_keywords a no-op on Ruby <= 2.6 and make *args behave like ... on Ruby 2.7+.

---

I think both of these are easier to understand than ruby2_keywords, and both don't need to have any performance trade-off on unrelated code (#16188).

I'd like to have the opinion of the core team on this.
It has been suggested multiple times (notably in my blog post on 10 November), but I have not seen any opinion on this tracker about it.

[jeremyevans0 (Jeremy Evans)]

I'm against backporting features (not just this particular feature) to already released ruby versions. For one, not everyone runs on the latest tiny release, and having different feature sets in tiny versions is likely to lead to user confusion. Users currently have an expectation that tiny releases only include bug fixes, and backporting any features results in a slippery slope.

In regards to pass_keywords, this wouldn't even be a backport, this would be a brand new feature, as pass_keywords isn't implemented in the master branch. The rejected pull request that implemented pass_keywords doesn't handle the case given as it uses a separate VM frame.

In regards to ..., it only handles delegation of all arguments, so it is only useful in a subset of argument forwarding cases. It is also implemented using ruby2_keywords internally, so backporting it would require backporting ruby2_keywords, which you seem to be against.

[Eregon (Benoit Daloze)]

jeremyevans0 (Jeremy Evans) wrote:

In regards to pass_keywords, this wouldn't even be a backport, this would be a brand new feature, as pass_keywords isn't implemented in the master branch.

It would be a new method in Ruby 2.7, yes, much like ruby2_keywords.
Older versions can just implement pass_keywords as a no-op (e.g., in a compatibility gem).

[jonathanhefner (Jonathan Hefner)]

Eregon (Benoit Daloze) wrote:

I've heard quite a few people saying that backporting ... to Ruby 2.4-2.6 would be a good way to do migration for keyword arguments.

To me, as a gem maintainer, this sounds like the most appealing option. But I understand that for the Ruby maintainers this is probably the least appealing option.

If we don't want to backport ..., there is also the option to use pass_keywords like so ...
I think both of these are easier to understand than ruby2_keywords, and both don't need to have any performance trade-off on unrelated code (#16188).

For those reasons I agree that pass_keywords, as presented, seems preferable to ruby2_keywords. Though I don't know enough about Ruby internals to criticize it.

jeremyevans0 (Jeremy Evans) wrote:

For one, not everyone runs on the latest tiny release, and having different feature sets in tiny versions is likely to lead to user confusion.

This is a good point.

Has anyone proposed implementing pass_keywords as a pragma comment? Doing so would avoid the need for a no-op definition, whether via backport or extra compatibility gem.

[matz (Yukihiro Matsumoto)]

As a general principle, I agree with Jeremy. But for this case only, @Eregon's "90% compatibility" sounds too tempting.
When we need to ask upgrading Ruby versions, it's far easier for users to upgrade within 2.5 or 2.6 than to 2.7 (or 3.0).

I am not going to rename ruby2_keywords to pass_keywords. It is ugly, but it should be disappeared after 2.6 EOL. So it's intentional.

Matz.

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Closed