Issue #16853 has been updated by sylvain.joyeux (Sylvain Joyeux).


Hi Yusuke. Thanks for the long thought-out answer. I really appreciate you taking the time.

> But the behavior was changed to reject non-symbol keys, and it was done without matz's confirmation. So in a sense, this is a bug fix.

It feels like a very "ruby-core centric" perspective. This "bug" was advertised loudly with an exception for 6 years (2.1 to just-before 2.7) while it did "not exist" for one. In addition, keyword arguments started in 2.0, which means that people like me were likely to start migrating to keyword arguments later, and gradually.

Once something is "true" for such a long period, it has to be considered the established behavior. The very fact that you try to gently migrating to "pure" keyword arguments says it.

> The reason why it was changed is because there are some methods that want to accept both symbol and non-symbol keys: where(id: 42) and where("table.id" => 42).

So, because Rails. I was guessing that it would be the driver.

Now, should really the others be damned ? All the other people have to add `{}` but Rails gets a backward-incompatible core change to be able to continue doing what they do ?

Which, by the way, also hints that Rails had as of yet not migrated their `where` method to use keyword arguments ? This is what I said on the Rails Discussion thread: that next time I'll do the same and wait until the very last minute. At least, I'll be sure.

I don't mind having the change *in the long run*. But from where I stand, this looks like a backward-incompatible change that's been added to allow for forward-compatibility to please one actor in the community. One very big actor, I grant you that.

This is really bad when you are not that actor (or not using that actor's framework). What I feel is that "because rails" is breaking trust for "anybody that's not rails".  Some people are vocal that Ruby is not Rails, but this kind of decisions speak volumes. Which is natural in some way, I guess, given how big Rails is in the community.

> To know your pain point precisely, I'd like to ask you a question: can you manually separate non-symbol keys?

I am peppering my codebase with those, yes. The problem is that I also have to do that on forwarding methods to be compatible with the forward-breaking stuff in Ruby 2.6. So, has rather been a nightmare. I don't have a team of software engineers that can spend weeks on this stuff.

(I'm sorry to have taken so long to answer, but I thought I would get an email notification and I have not, I'll try and see how to make that happen)


----------------------------------------
Bug #16853: calling bla(hash, **kw) with a string-based hash passes the strings into **kw (worked < 2.7)
https://bugs.ruby-lang.org/issues/16853#change-86404

* Author: sylvain.joyeux (Sylvain Joyeux)
* Status: Rejected
* Priority: Normal
* ruby -v: 2.7.1p83
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN
----------------------------------------
The following code

~~~
def bla(hash = {}, **kw)
    puts "H: #{hash}"
    puts "K: #{kw}"
end

bla "some" => "string"
~~~

**silently** outputs the following (no warnings about deprecation of keyword parameters-from-hash)

~~~
H: {}
K: {"some"=>"string"}
~~~

While 2.6.5 (and versions before it) gave

~~~
H: {"some"=>"string"}
K: {}
~~~

I would expect "the warning" that started appearing in 2.7, and **definitely** not having strings in a keyword argument hash.



-- 
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>