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


mame (Yusuke Endoh) wrote:
> jeremyevans0 (Jeremy Evans) wrote:
> > Having to change all calls from `where(:id=>1)` to `where({:id=>1})` makes the code uglier and is going to make most Ruby programmers less happy.  Does this argument for explicitness lead to requiring parentheses for all method calls?
> 
> In this specific case, it looks better to change the callee side instead of the caller side: the method definition of `where` should receive a keyword rest argument.  Of course, it still requires us change some calls of `where(opt_hash)` to `where(**opt_hash)`, but I think it is better and clearer.

Changing the callee side will not fix all cases. The `where` method supports more than just symbols keys in hashes.  `where('table.id'=>1)` is supported, for example.  Accepting a keyword args splat and then appending it to the array of arguments just decreases performance for no benefit.

It is important to realize that keyword arguments are not a substitute for hash arguments, as keyword arguments only handle a subset of what a hash argument can handle.

mame (Yusuke Endoh) wrote:
> Here is a scenario where allowing "hash argument with omitted braces" causes a problem.  Assume that we write a method "debug" which is equal to "Kernel#p".
> 
> ```
> def debug(*args)
>   args.each {|arg| puts arg.inspect }
> end
> ```
> 
> Passing a hash argument with omitted braces, unfortunately, works.
> 
> ```
> debug(key: 42) #=> {:key=>42}
> ```
> 
> Then, consider we improve the method to accept the output IO as a keyword parameter "output":
> 
> ```
> def debug(*args, output: $stdout)
>   args.each {|arg| output.puts arg.inspect }
> end
> ```
> 
> However, this change breaks the existing call.

Note how this problem does not occur until you add keyword arguments to the method.  If you never add keyword arguments, you never run into this problem, and there are ways to add the support you want without using keyword arguments.

Are you assuming that all methods that use hash arguments will end up wanting to use keyword arguments at some point?  I think that is unlikely.  If keyword arguments are never added to the method in the future, then you have broken backwards compatibility now for no benefit.

You are implying it is better to certainly break tons of existing code now, to allow for a decreased possibility of breaking code later if and only if you decide to add keyword arguments.

> This is too easy to break.  So, what is bad?  I believe that passing a hash argument as a normal last parameter is bad.

That is an opinion I do not share.  I believe passing a hash argument as a normal last parameter is fine and one of the nice features that makes Ruby a beautiful language to write in.  I think omitting braces for hash arguments has a natural similarity to the ability to omit parentheses for method calls, which is another Ruby feature that makes it enjoyable to write in.

> I'd like to make it safe to extend an existing method definition with a keyword parameter.

Attempting to avoid backwards compatibility problems is a noble goal that I think we share.  Part of that is avoiding future backwards compatibility problems.  Another part of that is avoiding current backwards compatibility problems.  A change that causes more current backwards compatibility problems than the future backwards compatibility problems it is designed to avoid is a step in the wrong direction, in my opinion.

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

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

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