From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id C17861F404 for ; Sat, 1 Sep 2018 01:32:31 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 35F331209D2; Sat, 1 Sep 2018 10:32:29 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 58C4B1209D0 for ; Sat, 1 Sep 2018 10:32:26 +0900 (JST) Received: by filter0113p3las1.sendgrid.net with SMTP id filter0113p3las1-24759-5B89EC27-E 2018-09-01 01:32:23.63003431 +0000 UTC m=+8453.937230900 Received: from herokuapp.com (ec2-54-225-56-139.compute-1.amazonaws.com [54.225.56.139]) by ismtpd0040p1mdw1.sendgrid.net (SG) with ESMTP id h3bUREPuTnaL9FClvjh17Q Sat, 01 Sep 2018 01:32:23.414 +0000 (UTC) Date: Sat, 01 Sep 2018 01:32:23 +0000 (UTC) From: mame@ruby-lang.org To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 64172 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 14183 X-Redmine-Issue-Author: mame X-Redmine-Sender: mame X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS65hk7nHz0ZpbtS1uHdzRhHr1O2m9muI7tS1W KUGNZfAV/dihT77JQucplq1eg805xA/nCXlWHCV/+l4U2qt5utj3DBw7Im1l1WW7BdXkusQ9eKvs9W pniASvkBXzsM3WLdjJEXWDX+S9XcPqwn5du3AHOIOJCERYcO24gUqa3mlg== X-ML-Name: ruby-core X-Mail-Count: 88793 Subject: [ruby-core:88793] [Ruby trunk Feature#14183] "Real" keyword argument X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #14183 has been updated by mame (Yusuke Endoh). jeremyevans0 (Jeremy Evans) wrote: > Changing the callee side will not fix all cases. The `where` method supports more than just symbols keys in hashes. `where('table.id'=>1)` is supported, for example. Accepting a keyword args splat and then appending it to the array of arguments just decreases performance for no benefit. As an experiment, I'm now trying to check Ruby's existing APIs, and noticed that some methods had the issue: Kernel#spawn, JSON::GenericObject.from_hash, etc. It might be good to provide a variant of define_method for this case as a migration path: ``` define_last_hash_method(:foo) do |opt| p opt end foo(k: 1) #=> {:k=>1} foo("k"=>1) #=> {"k"=>1} ``` > Are you assuming that all methods that use hash arguments will end up wanting to use keyword arguments at some point? I think that is unlikely. If keyword arguments are never added to the method in the future, then you have broken backwards compatibility now for no benefit. I don't think that all methods will have keyword arguemnts eventually. However, I assume that we can never predict which methods will have. > > I'd like to make it safe to extend an existing method definition with a keyword parameter. > > Attempting to avoid backwards compatibility problems is a noble goal that I think we share. Part of that is avoiding future backwards compatibility problems. Another part of that is avoiding current backwards compatibility problems. A change that causes more current backwards compatibility problems than the future backwards compatibility problems it is designed to avoid is a step in the wrong direction, in my opinion. In general, I agree. For this specific topic, however, the current spec and implementation are really a mess; the current backward compatibility problem is relatively easy to fix; the future backwards compatibility problem is hard to avoid and will become painful more and more. We should now pay the debt for the future. But this is just my opinion. I really appreciate and respect your opinion. I'd like to tell matz your opinion as fairly as I can. ---------------------------------------- Feature #14183: "Real" keyword argument https://bugs.ruby-lang.org/issues/14183#change-73835 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal * Assignee: * Target version: Next Major ---------------------------------------- In RubyWorld Conference 2017 and RubyConf 2017, Matz officially said that Ruby 3.0 will have "real" keyword arguments. AFAIK there is no ticket about it, so I'm creating this (based on my understanding). In Ruby 2, the keyword argument is a normal argument that is a Hash object (whose keys are all symbols) and is passed as the last argument. This design is chosen because of compatibility, but it is fairly complex, and has been a source of many corner cases where the behavior is not intuitive. (Some related tickets: #8040, #8316, #9898, #10856, #11236, #11967, #12104, #12717, #12821, #13336, #13647, #14130) In Ruby 3, a keyword argument will be completely separated from normal arguments. (Like a block parameter that is also completely separated from normal arguments.) This change will break compatibility; if you want to pass or accept keyword argument, you always need to use bare `sym: val` or double-splat `**` syntax: ``` # The following calls pass keyword arguments foo(..., key: val) foo(..., **hsh) foo(..., key: val, **hsh) # The following calls pass **normal** arguments foo(..., {key: val}) foo(..., hsh) foo(..., {key: val, **hsh}) # The following method definitions accept keyword argument def foo(..., key: val) end def foo(..., **hsh) end # The following method definitions accept **normal** argument def foo(..., hsh) end ``` In other words, the following programs WILL NOT work: ``` # This will cause an ArgumentError because the method foo does not accept keyword argument def foo(a, b, c, hsh) p hsh[:key] end foo(1, 2, 3, key: 42) # The following will work; you need to use keyword rest operator explicitly def foo(a, b, c, **hsh) p hsh[:key] end foo(1, 2, 3, key: 42) # This will cause an ArgumentError because the method call does not pass keyword argument def foo(a, b, c, key: 1) end h = {key: 42} foo(1, 2, 3, h) # The following will work; you need to use keyword rest operator explicitly def foo(a, b, c, key: 1) end h = {key: 42} foo(1, 2, 3, **h) ``` I think here is a transition path: * Ruby 2.6 (or 2.7?) will output a warning when a normal argument is interpreted as keyword argument, or vice versa. * Ruby 3.0 will use the new semantics. -- https://bugs.ruby-lang.org/