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 D3C211F463 for ; Fri, 27 Dec 2019 00:42:34 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id C955B120A59; Fri, 27 Dec 2019 09:42:19 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id B8694120A4A for ; Fri, 27 Dec 2019 09:42:16 +0900 (JST) Received: by filterdrecv-p3las1-5bf99c48d-527wg with SMTP id filterdrecv-p3las1-5bf99c48d-527wg-18-5E055367-4C 2019-12-27 00:42:16.035965978 +0000 UTC m=+863786.771465682 Received: from herokuapp.com (unknown [54.84.189.171]) by ismtpd0118p1mdw1.sendgrid.net (SG) with ESMTP id 5QJJ_riqSYCTPH6CLVzy9Q for ; Fri, 27 Dec 2019 00:42:15.870 +0000 (UTC) Date: Fri, 27 Dec 2019 00:42:16 +0000 (UTC) From: aaronc20000@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 72167 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=2FvepzSSe8vie0VPxU8aM3vPWA7FprvHTUsXnFO=2FGLaLWsQVz?= =?us-ascii?Q?7ZYdc9lptFaQpjaILUpJYXzp7K=2FqL9Sq=2FWr3qDE?= =?us-ascii?Q?dADEMNjxKGswyENJMr3xuaoR1ZuAktLpokm9dH7?= =?us-ascii?Q?P5dqTwvpAI2vg4aNp=2F3SjAsb6AP04+BMt2k+WJ6?= =?us-ascii?Q?mlnvJSiRFp=2FA6daIzcsBlFlzKoZqPldXPfR1LXV?= =?us-ascii?Q?gupyVvJwpUHHvJXzo=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 96508 Subject: [ruby-core:96508] [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 reported by aaronc81 (Aaron Christiansen). ---------------------------------------- Feature #16456: Ruby 2.7 argument delegation (...) should be its own kind of parameter in Method#parameters https://bugs.ruby-lang.org/issues/16456 * 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`. ``` 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: ``` def foo(...); end p method(:foo).parameters # => [[:delegate, :"..."]] ``` -- https://bugs.ruby-lang.org/