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=-2.6 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=no 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 985151F463 for ; Fri, 27 Dec 2019 17:36:03 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 58E05120A3C; Sat, 28 Dec 2019 02:35:47 +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 EC534120A29 for ; Sat, 28 Dec 2019 02:35:44 +0900 (JST) Received: by filterdrecv-p3mdw1-56c97568b5-d7vf5 with SMTP id filterdrecv-p3mdw1-56c97568b5-d7vf5-18-5E0640F4-25 2019-12-27 17:35:48.512035877 +0000 UTC m=+924762.014926309 Received: from herokuapp.com (unknown [3.90.237.225]) by ismtpd0004p1iad2.sendgrid.net (SG) with ESMTP id KZM7-Uh_RV2s8U8OpJ-CWw for ; Fri, 27 Dec 2019 17:35:48.441 +0000 (UTC) Date: Fri, 27 Dec 2019 17:35:48 +0000 (UTC) From: aaronc20000@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 72176 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16456 X-Redmine-Issue-Author: aaronc81 X-Redmine-Sender: aaronc81 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?vDwfuvxx8qZ+B2=2FvepzSSe8vie0VPxU8aM3vPWA7FprFSRrVdG2Iyt3Lk9YUmL?= =?us-ascii?Q?+=2FiR3Iq7pZZsZYUMQy=2FQt3eq2B9Tf0O2JmPYvuX?= =?us-ascii?Q?YYANyFvgNM=2Fng5yFXE51mB4MSVxd5xgMJIfq7QX?= =?us-ascii?Q?Ald6NsrMdo0VmMGb8vhNPH1eVE57cXVaKxA=2Fa+8?= =?us-ascii?Q?NUK9LGWTKcE38MIpct9QjH=2Ff0jpJ8QS72eFn3hw?= =?us-ascii?Q?r65qZsSi1G3gr4TV8=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 96517 Subject: [ruby-core:96517] [Ruby master Feature#16456] Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters 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 #16456 has been updated by aaronc81 (Aaron Christiansen). > Is there an advantage to have its own type of parameter? I believe the advantages of doing this are: - If Ruby ever introduces a new type of parameter, the result of `#parameters` won't need to change for existing code which uses `...`, making upgrades easier. This is especially important if `...` is designed as a future-proof way of delegation, as then it seems important that its behaviour shouldn't change between versions. - It could be useful for introspection to be able to differentiate between the two. For example, this could allow a complex DSL to assign a special meaning to `...`. ---------------------------------------- Feature #16456: Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters https://bugs.ruby-lang.org/issues/16456#change-83449 * Author: aaronc81 (Aaron Christiansen) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- A method defined with `...` as its parameter list is equivalent to one defined with `*args, &blk`, according to `Method#parameters`. ```ruby def foo(...); end p method(:foo).parameters # => [[:rest, :*], [:block, :&]] ``` Even in Ruby 2.7, `...` and `*args, &blk` are not *quite* equivalent as the latter may produce a warning where the former does not. In Ruby 3.0 and beyond, `...` and `*args, &blk` will have a substantial semantic difference. Due to this, I don't consider the current behaviour of `Method#parameters` particularly ideal when dealing with methods using this new syntax. If the goal of `...` is to be a "delegate everything" operator, even when parameter passing is changed like in Ruby 3.0, I would propose that `Method#parameters` considers it a unique type of parameter. For example: ```ruby def foo(...); end p method(:foo).parameters # => [[:delegate, :"..."]] ``` -- https://bugs.ruby-lang.org/