Issue #20513 has been updated by jeremyevans0 (Jeremy Evans). zverok (Victor Shepelev) wrote in #note-3:
``` — So, for your custom object to have `[]`, you just `def []`, like it is a common method! — Oh, nice! I like how there are ground rules and everything is conforming to them! ... — Oh, I expermented with it a bit, and for some reason, `colored_hash[:key, color: :red]` doesn’t work?.. What am I doing wrong?.. Is it a bug?.. — You see, young padawan... Many versions ago, there was that thing about Keyword Argument Separation. And when it was being done, we forgot to handle the `[]` situation... And then, in a few years, when it was handled, in order to not break some code slightly, we just removed the feature. — Ugh. ```
If you are going to complain about a change using a hypothetical, at least get the details correct, otherwise you appear not to know what you are talking about. The example you gave still works, because it isn't an assignment.
I mean, looking at the language with a fresh eye, “something semantically clear and conforming to the existing intuitions doesn’t work because it was prohibited arbitrarily during one historical transition” might be really harmful for the language’s image.
It isn't intuitive behavior to have keyword argument separation in all other methods and not aset/op_asgn/masgn. It isn't intuitive behavior to insert the rhs of an assignment between the positional and keyword arguments of the lhs. ---------------------------------------- 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-108525 * 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