From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 5ADA71F461 for ; Mon, 2 Sep 2019 21:44:13 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 31754120ABE; Tue, 3 Sep 2019 06:43:55 +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 9377D120A18 for ; Tue, 3 Sep 2019 06:43:52 +0900 (JST) Received: by filter0049p3iad2.sendgrid.net with SMTP id filter0049p3iad2-10045-5D6D8D18-32 2019-09-02 21:43:52.959094162 +0000 UTC m=+526743.365929043 Received: from herokuapp.com (unknown [54.242.66.142]) by ismtpd0001p1iad1.sendgrid.net (SG) with ESMTP id rKvBjUygQlGjkiLiWJHczg for ; Mon, 02 Sep 2019 21:43:52.787 +0000 (UTC) Date: Mon, 02 Sep 2019 21:43:52 +0000 (UTC) From: merch-redmine@jeremyevans.net Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 70302 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 14183 X-Redmine-Issue-Author: mame X-Redmine-Sender: jeremyevans0 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: =?us-ascii?Q?RVE3t853K5scBhbmJHUzZTFFeVC=2FZSUmHZ0Dc+26wcEi2CTgsF1oz0wTSSxGGN?= =?us-ascii?Q?BIyq96wUVyRFTxASozxcVv55expGZOCK=2FCslD66?= =?us-ascii?Q?Ypu9BtLhdfIVAaDopzZsCtbZN=2FiLwa09Cl7cXUL?= =?us-ascii?Q?AeUYUotlkpDLsFBJEpMFilie2fcz3m21P+sqE8P?= =?us-ascii?Q?uMUCp+zQHa=2F1GbyjzAO31j1BfxCAU50jFMA=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 94748 Subject: [ruby-core:94748] [Ruby master 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 jeremyevans0 (Jeremy Evans). Dan0042 (Daniel DeLorme) wrote: > So far the only edge case I can think of is related to keyword extension: > > ```ruby > def my_puts(*args, out: $stdout, **kw) > args << kw unless kw.empty? > out.puts(*args) #args.last is KwHash, so it will be promoted to kwarg if out.puts supports keyword args > end > #behavior above may be acceptable, or: > def my_puts(*args, out: $stdout, **kw) > args << kw.dup unless kw.empty? #dup to convert KwHash to Hash > out.puts(*args) > end > ``` There are probably many edge cases with this approach. Here's an example of one such edge case: ```ruby def foo(*args, **kw) [args, bar(kw)] end def bar(hash={}, skip: false) hash unless skip end # Ruby 2.6 behavior: foo # [[], {}] foo(:a=>1) # ArgumentError: unknown keyword: :a ``` Here, the intention is to pass the keyword arguments from one method as a positional hash to another method. This is one of the cases that currently breaks in 2.6, that will warn and break in 2.7, and that will be fixed in Ruby 3. With your approach, it will remain broken, since `kw` in `foo` will be implicitly converted to keyword arguments to `bar`. This leads to the same types of problems that keyword argument separation is designed to prevent. Any form of automatic conversion of positional hashes to keyword arguments and vice versa is going to have corner cases like these. I understand that keyword argument separation is going to require updating some code. It is not going to be fully backwards compatible for methods that accept keyword arguments. The good news is that if you don't use keyword arguments in your methods, the behavior will remain backwards compatible. Additionally, any cases that will break will be warned about in Ruby 2.7 so you can update the related code. ---------------------------------------- Feature #14183: "Real" keyword argument https://bugs.ruby-lang.org/issues/14183#change-81366 * Author: mame (Yusuke Endoh) * Status: Closed * 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. ---Files-------------------------------- vm_args.diff (4.19 KB) vm_args_v2.diff (4.18 KB) -- https://bugs.ruby-lang.org/