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


zverok (Victor Shepelev) wrote:
> The problem with blocks is indeed Array/Enumerable (and similar code). I am not sure how widespread this approach is, but in our production code (lots of small hashes, too many and to short-living to wrap in objects), we frequently do this:
> ```ruby
> words
>   .select { |paragraph_id:, text:, **| paragraph_id > first_paragraph_id && !text.include?('foo') }
>   .map { |text:, timestamp:, **| {at: timestamp.to_i, content: "#{text} [#{timestamp}]"} }
>   .group_by { |at:, **| at % 1000 }
> 
> # Or even:
> large_config_hash.then { |this_value:, that_value: DEFAULT, **| do_something(this_value, that_value) }
> ```
> This allows constructing readable chains of expressive transformations, which `Hash#fetch`/`Hash#[]` would make arguably much less clear.
> 
> It seems keyword argument separation just clearly prohibits this technique without any alternative (of the same expressiveness).

You are correct that this style will no longer be supported without modification or overriding of Array/Enumerable methods.  I think switching to a `Hash#fetch`/`Hash#[]` approach would not make the code less clear or less expressive, but that is subjective.  A `Hash#fetch`/`Hash#[]` approach is certainly going to be faster, saving at least one hash allocation per block call.

In most cases a `Hash#[]` approach will be more concise since you don't have to repeat the keys.  For example:

```ruby
.select { |h| h[:paragraph_id] > 0 && !h[:text].include?('foo') }
.map { |h| {at: h[:timestamp].to_i, content: "#{h[:text]} [#{h[:timestamp]}]"} }
.group_by { |h| h[:at] % 1000 }
```

The `Hash#[]` approach reduces the character count in each line:

* select: 80 -> 65
* map: 88 -> 80
* group_by : 33 -> 31

A `Hash#fetch` approach will probably be longer, and for mandatory keywords, that would be a more accurate translation.

Keyword arguments were introduced to Ruby to make API design more flexible, as mentioned in the Ruby 2.0.0 release announcement.  They were not intended as a hack to extract data from hashes.  We actually have a new hack for extracting data from hashes:

```ruby
.select { |h| h in {paragraph_id: paragraph_id, text: text}; paragraph_id > 0 && !text.include?('foo') }
.map { |h| h in {text: text, timestamp: timestamp}; {at: timestamp.to_i, content: "#{text} [#{timestamp}]"} }
.group_by { |h| h in {at: at}; at % 1000 }
```

It is still experimental, though. :)

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

* Author: mame (Yusuke Endoh)
* Status: Closed
* 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>