Issue #20513 has been updated by zverok (Victor Shepelev).
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
Could you please stop with this sort of veiled references? If you got a problem say it.
I am really sorry if my statement was perceived as offensive, and even more so if it was perceived as implying somebody in particular. I see how it can be read this way, and it is 100% the fault of my wording, but it was _not_ what I intended to say, even less so to “shit on” somebody. I believe that all of the core team members (active currently or in the past) are acting in good faith and are stellar professionals. I believe that deep internal changes in the language achieved in the last versions were extremely good and tough engineering. The only thing I was trying to say (phrasing it in an absolutely unfortunate way) is that many discussions are currently driven by the fact that Ruby is perceived by many of its users and maintainers as a tool to create and maintain large production (mostly Rails) codebases, and corresponding industry practices. My main paid Ruby job is also related to the large production Rails codebase and I fully appreciate all changes that make its development and maintenance easier. At the same time, I care deeply about the language as a tool of thought, and changing it (or refusing to make so) towards less pliability or semantical flexibility makes me sad. The fact that makes me more sad is that such discussions tend to be quite conservative (and not only in the sense of scrutinizing new APIs/syntaxes, but even doubting the utility of existent, if less used, ones). I don’t think that it is anybody’s “fault” or that I am somehow “smarter” than somebody else; I just wanted to highlight this fact. I didn’t mean any personal or generic offense to anybody. ---------------------------------------- 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-108526 * 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