Issue #14183 has been updated by jeremyevans0 (Jeremy Evans).


mame (Yusuke Endoh) wrote:
> However, akr and I think that "2.7 is completely compatible with 2.6 except warnings" approach is not good enough.  We need to provide a migration path that allows users to rewrite their code for 3.0 gradually.  So, Ruby 2.7 must run (reasonably almost) all programs that are valid as either 2.6 or 3.0.  (I expected the above proposal to be good enough, but turned out somewhat too breaking.)
> 
> In other words, if a warning is printed, there must be a reasonable change that is not warned (i.e., will work in 3.0) and that causes no behavior change (in, at least, 2.7 semantics).

I agree we should aim for this.  I think it is true with my proposal, but there may be cases I have not considered.

> Consider delegation.  Currently we write:
> 
> ```
> # we call this "old-style delegation"
> def foo(*args, &blk)
>   bar(*args, &blk)
> end
> ```
> 
> but this is warned when keywords are passed.  So we'd like to rewrite it as:
> 
> ```
> # we call this "new-style delegation"
> def foo(*args, **kw, &blk)
>   bar(*args, **kw, &blk)
> end
> ```
> 
> However, this rewrite changes the behavior unfortunately in 2.6 semantics because of the problem "2. Explicit Delegation of keywords backfires"
> 
> ```
> def bar(*args)
>   p args
> end
> 
> def foo0(*args, &blk)
>   bar(*args, &blk)
> end
> 
> def foo1(*args, **kw, &blk)
>   bar(*args, **kw, &blk)
> end
> 
> bar()  #=> []
> foo0() #=> []
> foo1() #=> [{}] # broken
> ```
> 
> `rb_no_keyword_hash` trick works gracefully in this case.  The trick allows the new-style delegation in (almost) 2.6 semantics.  So the hack is needed, we think.

The `rb_no_keyword_hash` hack is not needed in my branch, as my branch returns `[]` for `bar`, `foo0`, and `foo1`, since double-splatting empty hashes to a method that does not accept keyword arguments does not pass a positional hash in my branch.

I think using the `rb_no_keyword_hash` hack will cause problems, because it treats some empty hashes different from other empty hashes.  Consider the following case, where you want to limit which keyword arguments are passed when delegating:

```ruby
ALLOWED_KEYWORDS = [:baz, :quux]
def foo2(*args, **kw, &blk)
  kw = kw.select{|k| ALLOWED_KEYWORDS.include?(k)}
  bar(*args, **kw, &blk)
end
```

This could be fixed by switching to a mutating method (`select!`), though.

> You registered this ticket for pre-RubyKaigi [Misc#15459].  Do you have an idea how to discuss the issue?
> 
> @ko1 is now creating an agenda, and maybe 30 minutes will be allotted to this issue.  The agenda is not decided yet, though.
> 
> To make it easy to discuss the issue, I'm creating a slide deck.
> 
> https://docs.google.com/presentation/d/16rReiCVzUog3s5vV702LzcIFM2LNcX53AX8m5K8uCZw
> 
> I hope that this would be helpful and fair, but could you check the content?  If you want to edit it yourself, emaiil me (mame / ruby-lang.org) your google acount.

I briefly reviewed your slide deck and I think it does a good job explaining the various aspects of this issue, and I think we should present it during the developer meeting.  I will do a more thorough review later today and email you if I have any suggested changes to the slides.

----------------------------------------
Feature #14183: "Real" keyword argument
https://bugs.ruby-lang.org/issues/14183#change-77591

* Author: mame (Yusuke Endoh)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: Next Major
----------------------------------------
In RubyWorld Conference 2017 and RubyConf 2017, Matz officially said that Ruby 3.0 will have "real" keyword arguments.  AFAIK there is no ticket about it, so I'm creating this (based on my understanding).

In Ruby 2, the keyword argument is a normal argument that is a Hash object (whose keys are all symbols) and is passed as the last argument.  This design is chosen because of compatibility, but it is fairly complex, and has been a source of many corner cases where the behavior is not intuitive.  (Some related tickets: #8040, #8316, #9898, #10856, #11236, #11967, #12104, #12717, #12821, #13336, #13647, #14130)

In Ruby 3, a keyword argument will be completely separated from normal arguments.  (Like a block parameter that is also completely separated from normal arguments.)
This change will break compatibility; if you want to pass or accept keyword argument, you always need to use bare `sym: val` or double-splat `**` syntax:

```
# The following calls pass keyword arguments
foo(..., key: val)
foo(..., **hsh)
foo(..., key: val, **hsh)

# The following calls pass **normal** arguments
foo(..., {key: val})
foo(..., hsh)
foo(..., {key: val, **hsh})

# The following method definitions accept keyword argument
def foo(..., key: val)
end
def foo(..., **hsh)
end

# The following method definitions accept **normal** argument
def foo(..., hsh)
end
```

In other words, the following programs WILL NOT work:

```
# This will cause an ArgumentError because the method foo does not accept keyword argument
def foo(a, b, c, hsh)
  p hsh[:key]
end
foo(1, 2, 3, key: 42)

# The following will work; you need to use keyword rest operator explicitly
def foo(a, b, c, **hsh)
  p hsh[:key]
end
foo(1, 2, 3, key: 42)

# This will cause an ArgumentError because the method call does not pass keyword argument
def foo(a, b, c, key: 1)
end
h = {key: 42}
foo(1, 2, 3, h)

# The following will work; you need to use keyword rest operator explicitly
def foo(a, b, c, key: 1)
end
h = {key: 42}
foo(1, 2, 3, **h)
```

I think here is a transition path:

* Ruby 2.6 (or 2.7?) will output a warning when a normal argument is interpreted as keyword argument, or vice versa.
* Ruby 3.0 will use the new semantics.

---Files--------------------------------
vm_args.diff (4.19 KB)
vm_args_v2.diff (4.18 KB)


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

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