Feature #16511
Updated by Dan0042 (Daniel DeLorme) almost 5 years ago
As an alternative to #16463 and #16494 I'd like to propose this approach, which I believe allows a **much** more flexible path for migration of keyword arguments.
The idea is to have a subclass of Hash (let's name it "KwHash") which provides a clean, object-oriented design with various benefits.
I'll try to describe the idea by breaking it down into figurative steps. Imagine starting with ruby 2.6 and then:
### Step 1
When a double-splat or a brace-less hash is used, instead of a Hash it creates a KwHash.
```ruby
def foo(x) x end
foo(k:1).class #=> KwHash
foo(**hash).class #=> KwHash
[k:1].last.class #=> KwHash
[**hash].last.class #=> KwHash
{**hash}.class #=> Hash
```
At this point we haven't introduced any real change. Everything that worked before is still working the same way, with the ONLY exception being code like `kw.class == Hash` which now returns false. But no one actually writes code like that; it's always `kw.is_a?(Hash)`, which still returns true.
### Step 2
When there is ambiguity due to optional vs keyword argument, we rely on the last argument being Hash or KwHash to disambiguate.
```ruby
def foo(x=nil, **kw)
[x,kw]
end
foo({k:1}) #=> [{k:1},{}]
foo(k:1) #=> [nil,{k:1}]
```
This is the _minimum_ amount of incompatibility required to solve ALL bugs previously reported with keyword arguments. (#8040, #8316, #9898, #10856, #11236, #11967, #12104, #12717, #12821, #13336, #13647, #14130, etc.)
### Step 3
Introduce additional incompatibility to improve clarity of design. Here we deprecate the automatic conversion of Hash to keyword argument; only KwHash is accepted. And always use the last KwHash argument if the method supports keyword arguments. With a deprecation/warning phase, of course. The "automatic" promotion of a KwHash to a keyword argument follows the same rules as a Hash in 2.6; since the KwHash is conceptually intended to represent keyword arguments, this conversion makes sense in a way that a normal data Hash doesn't. We've taken the "last positional hash" concept and split it into "conceptually a hash" and "conceptually keyword arguments". _Most importantly_, But importantly, all the changes required to silence these warnings are _compatible with 2.6_.
```ruby
def foo(x, **kw); end
foo(k:1) # ArgumentError because x not specified
foo(1, {k:1}) # ArgumentError because too many arguments; Hash cannot be converted to KwHashs
opts = [k:1].first
foo(opts) # opts is a KwHash therefore used as keyword argument; ArgumentError because x not specified
foo(1, opts) # opts is a KwHash therefore used as keyword argument
```
At this point we have achieved _almost-full_ _full_ **dynamic** keyword separation, as opposed to the current _almost-full_ **static** approach. I want to make the point here that, yes, keyword arguments **are** separated, it's just a different paradigm. With static separation, a keyword argument is defined lexically by a double-splat. With dynamic separation, a keyword argument is when the last argument is a KwHash. {{Note: I'm saying "almost-full" because KwHash is not promoted to keywords in `def foo(a,**kw);end;foo(x:1)` and because static keywords are auto-demoted to positional in `def foo(a);end;foo(x:1)`]
Any form of delegation works with no change required. This preserves the behavior of 2.6 but only for KwHash objects. This is similar to having 2.7 with `ruby2_keywords` enabled by default. But also different in some ways; most notably ways. _Most importantly_, it allows the case shown in #16494 to work by default:
```ruby
array = [x:1]
array.push(x:2)
array.map{ |x:| x } #=> [1,2]
```
The current approach does not allow this to work at all. The solution proposed in #16494 has all the same flaws as Hash-based keyword arguments; what happens to `each{ |x=nil,**kw| }` ? The subclass-based solution allows a KwHash to be converted to... keywords. Very unsurprising.
Given that ruby is a dynamically-typed language I feel that dynamic typing of keywords if a more natural fit than static typing. But I realize that many disagree with that, which is why we continue to...
### Step 4
Introduce additional incompatibility to reach static/lexical separation of keyword arguments. Here we require that even a KwHash should be passed with a double-splat in order to qualify as a keyword argument.
```ruby
def bar(**kw)
end
def foo(**kw)
bar(kw) #=> error; KwHash passed without **
bar(**kw) #=> ok
end
```
At this point we've reached the same behavior as 2.7. Delegation needs to be fixed, but as we know the changes required to silence these warnings are **not** compatible with 2.6. So here we introduce a way to _silence **only** these "Step 4" warnings_, for people who need to remain compatible with 2.6. And we keep them as warnings instead of errors until ruby 2.6 is EOL.
So instead of having to update a bunch of places with `ruby2_keywords` right now, it's a single flag like `Warning[:ruby3_keywords]`. Once ruby 2.6 is EOL these become controlled by `Warning[:deprecated]` which tells people they **have** to fix their code. Which is just like the eventual deprecation of `ruby2_keywords`, just without the busy work of adding `ruby2_keywords` statements in the first place.
The question remains of how to handle #16494 here. Either disallow it entirely, but I think that would be a shame. Or just like #16494 suggests, allow hash unpacking in non-lambda Proc. Except that now it can be a KwHash instead of a Hash, which at least preserves dynamic keyword separation.
## Putting it all together
The idea is _not_ to reimplement keyword argument separation; all that is needed is to implement the things above that are not in 2.7:
* Create a KwHash object when a double-splat is used.
* If a warning is due to a KwHash instead of a Hash, make it a different kind of warning that can be toggled off separately from the Hash warnings (and that will stay as warnings until 2.6 is EOL)
I think that's all, really...
### Pros
* Cleaner way to solve #16494
* Better compatibility (at least until 2.6 is EOL)
* delegation
* storing an argument list that ends with a KwHash
* destructuring iteration (#16494)
* We can avoid the "unfortunate corner case" as described in the [release notes](https://www.ruby-lang.org/en/news/2019/12/12/separation-of-positional-and-keyword-arguments-in-ruby-3-0/)
* in 2.7 only do not output "Step 4" warnings, leave delegation like it was
* in 2.8 the "Step 3" warnings have been fixed and a Hash will not be converted to keyword arguments
* delegation can now safely be fixed to use the `**` syntax
* ruby2_keywords is not required, which is desirable because
* it's a hidden flag _hack_
* it requires to change the code now, and change it _again_ when ruby2_keywords is deprecated; twice the work; twice the gem upgrades
* it was supposed to be used only for people who need to support 2.6 or below, but it's being misunderstood as an acceptable way to fix delegation in general
* there's the non-zero risk that ruby2_keywords will never be removed, leaving us with a permanent "hack mode"
* dynamic keywords are by far preferable to supporting ruby2_keywords forever
* Likely _better performance_, as the KwHash class can be optimized specifically for the characteristics of keyword arguments.
* More flexible migration
* Allow more time to upgrade the hard stuff in Step 4
* Can reach the _same_ goal as the current static approach
* Larger "support zone" https://xkcd.com/2224/
* Instead of wide-ranging incompatibilities all at once, there's the _possibility_ of making it finer-grained and more gradual
* rubyists can _choose_ to migrate all at once or in smaller chunks
* It hedges the risks by keeping more possibilities open for now.
* It allows to cop-out at Step 3 if Step 4 turns out too hard because it breaks too much stuff
### Cons
* It allows to cop-out at Step 3 if Step 4 turns out too hard because it breaks too much stuff