Issue #20513 has been updated by zverok (Victor Shepelev).
but that a removal of a long-standing feature deserves more consideration and deliberation than the following
I wholeheartedly agree with this. I feel like a lot of “keyword arguments separation leftovers” (and not only) are removed in this manner, hurting the language’s image. A lot of things that are intuitively following from the common rules of syntax/semantics, and always worked, and even if used rarer than others, brought joy when tried or used for small private DSLs, suddenly just stop working or not follow the entire language dynamics/evolution. I understand that currently, the main driver for said evolution is maintainers of huge Rails codebases where squeezing out a few percent of performance is more important than the joy of the language, but I never felt comfortable with this direction. The logic of “`#[]` is a method, so you can use in its definition/call whatever you can use in other methods” is beautifully simple and consistent. Even if it brings some implementation complexities, this follows the always-present logic of Ruby: complex internally language for writing simple and beautiful code. But in recent years, arguments of “let’s simplify the implementation, so what if it breaks some of the consistency, no big amount of devs should want this anyway, and you can’t prove otherwise” seem to have grown deeper into the development process, and it is sad to see. I always felt that the main argument for Ruby’s structure was “if it is semantically consistent and logically clear, it should work.” Nowadays, the frequent argument is “until there is strong proof it is needed in production code (and this proof would meet the harshest scrutiny), we can drop that.” My two go-to examples: 1. Once, `something.map { |foo:, bar: "default"| ...` was a beautiful and convenient idiom, making keyword arguments more accepted and demonstrating Ruby’s flexibility. On “keyword args separation,” it was just dropped, and no as clear and convenient replacement exists; 2. When anonymous argument passing was introduced, it was prohibited for blocks (instead of keeping them on par with methods), even though small blocks might benefit enormously from this. ---------------------------------------- Bug #20513: the feature of kwargs in index methods has been removed without due consideration of utility and compatibility https://bugs.ruby-lang.org/issues/20513#change-108520 * Author: bughit (bug hit) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- See #20218 The ability to pass kwargs to index methods has been in ruby for a long time, probably from the inception of kwargs, so there's code that makes use of it. Other than the multiple assignment edge-case it's been working fine and is not conceptually unsound. kwargs allow for more variability in store/lookup operations via index methods, letting you control where/how something is stored/looked up. this is from 2.6 ```ruby module IndexTest @store = {} def self.store @store end def self.key(name, namespace: nil) name = "#{namespace}:#{name}" if namespace name end def self.[](name, namespace: nil) p [name, namespace] @store[key(name, namespace: namespace)] end def self.[]=(name, opts = {}, val) p [name, opts, val] @store[key(name, namespace: opts[:namespace])] = val end end IndexTest['foo'] = 1 p IndexTest['foo'] IndexTest['foo', namespace: 'bar'] = 2 p IndexTest['foo', namespace: 'bar'] p IndexTest.store ``` A reasonable breaking change would be for `[]=` to have real kwargs, rather than the middle positional kwarg collector hash in the above example. I am not arguing that breaking changes can't be introduced, but that a removal of a long-standing feature deserves more consideration and deliberation than the following:
I found that use of keyword arguments in multiple assignment is broken Can we also prohibit keyword arguments ... ? OK, prohibit keyword arguments