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=AWL,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 231191F463 for ; Fri, 27 Dec 2019 11:37:06 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 6C4DE120A8D; Fri, 27 Dec 2019 20:36:54 +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 68730120A7E for ; Fri, 27 Dec 2019 20:36:52 +0900 (JST) Received: by filterdrecv-p3las1-5bf99c48d-z5dx7 with SMTP id filterdrecv-p3las1-5bf99c48d-z5dx7-18-5E05ECDC-2A 2019-12-27 11:37:00.660981091 +0000 UTC m=+903076.614363356 Received: from herokuapp.com (unknown [3.90.237.225]) by ismtpd0053p1iad1.sendgrid.net (SG) with ESMTP id WYNdZXsOQ1ezQI2sQDe6fg for ; Fri, 27 Dec 2019 11:37:00.478 +0000 (UTC) Date: Fri, 27 Dec 2019 11:37:00 +0000 (UTC) From: zverok.offline@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 72172 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16456 X-Redmine-Issue-Author: aaronc81 X-Redmine-Sender: zverok 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?3be0g8093pjUjT94eiCA64csFDBI=2FmHQTWm54P5gda6+vLjmwvi+FXtx5pkRvg?= =?us-ascii?Q?tXyijX+4f9tol1eugXPrYRv7lcejSJCsX7uQXrp?= =?us-ascii?Q?au=2FEceAVqOF+4n4nLk4PLcc2RldqmTyRiNcqkvt?= =?us-ascii?Q?kiRg4+0a=2FI8YH0y4qQV4sOK+nTgEFtIO2K6RF0w?= =?us-ascii?Q?iBAeEvF8JJDukSvP1Fq7RvmcU=2FmOwx98FZElFU8?= =?us-ascii?Q?JYGqnzyAiD0CvVTfI=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 96513 Subject: [ruby-core:96513] [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 zverok (Victor Shepelev). > I think it should be: ```ruby [[:rest, :*], [:keyrest, :**], [:block, :&]] ``` (I have a deja vu we already discussed it :))) Names are redundant, it should be just ```ruby [[:rest], [:keyrest], [:block]] ``` Like this: ```ruby def foo(*, **, &b) end p method(:foo).parameters # => [[:rest], [:keyrest], [:block, :b]] ``` (Not sure about "block" parameter -- unnamed block parameters aren't existing in current Ruby) ---------------------------------------- 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-83445 * 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/