[ruby-core:88843] [Ruby trunk Feature#14183] "Real" keyword argument

[mame@ruby-lang.org]

Issue #14183 has been updated by mame (Yusuke Endoh).


Eregon (Benoit Daloze) wrote:
> I would think the number of methods like debug() is a tiny fraction of the number of places we'd need to change if hash-without-braces is no longer supported.
>
> IMHO such a method with rest + kwargs seems a bad design in the first place as the arguments are too complex. That debug method could only accept one argument for instance.

I think you are too familiar with the current weird keyword arguments.  The original and primary purpose of keyword arguments is an extension of existing methods.  It looks rather "too complex" for a mere addition of keyword parameters to disturb other parameters and to break existing calls.

That being said, I agree that the "cancer" of this issue is a combination of rest/optional agruments and keyword ones.  Another, more modest idea that I have is, to prohibit (or just warn) a method definition that has both rest/optional + keyword parameters.  I don't like this because this spoils the purpose of keyword arguments, though.


> Also, how should `foo(1, "foo" => "bar")` behave?
> Should it be like `foo(1, {"foo" => "bar"})`?

I think so.

> In this case the syntax is inconsistent with `foo(1, foo: "bar")` where having or leaving out the braces matter.

Braced hash and bare one are inconsistent, even in the current spec.

```
def foo(v=:default)
  p v
end

h={}
foo( **h )    #=> {}
foo({**h})    #=> {}
foo(1,  **h ) #=> 1
foo(1, {**h}) #=> wrong number of arguments (given 2, expected 0..1)
```

Note that `**{}` does not simply mean "no argument".  If it was "no argument", the above `foo(**h)` would print `:default` instead of `{}`.

> Or does the `=>` imply the braces?
> I believe all Rubyists are used to `foo(1, :foo => "bar")` and  `foo(1, foo: "bar")` being identical.

They will be still identical because it is determined not only syntactically but also dynamically: a key-value pair whose key is a Symbol, is handled as keyword argument.  This behavior is not new.  Ruby 2.5 even does it:

```
def foo(h1=nil, **h2)
  p [h1, h2]
end
foo("foo" => 1, :bar => 2, baz: 3) #=> [{"foo"=>1}, {:bar=>2, :baz=>3}]
```

(This behavior has been changed in trunk, but I'm unsure if it is determined or not.)


> BTW, `p foo: 1` will no longer work then, and `p({foo: 1})` would be required, which feels very *unlike* Ruby, and is just impractical when debugging.

I completely agree with this.  I showed the method `debug` as an example, but I don't think that `Kernel#p` itself should change.  Some existing APIs that people expect to accept both `foo(k:1)` and `foo({k:1})`, e.g, `ERB#result_with_hash`, Sequel's `where`, should be kept as well.

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

* 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.



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