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.8 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 B07421F454 for ; Sun, 10 Nov 2019 10:20:51 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 8D05A120970; Sun, 10 Nov 2019 19:20:40 +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 7AA62120965 for ; Sun, 10 Nov 2019 19:20:38 +0900 (JST) Received: by filter0094p3las1.sendgrid.net with SMTP id filter0094p3las1-19867-5DC7E477-24 2019-11-10 10:20:39.616001041 +0000 UTC m=+217816.885619873 Received: from herokuapp.com (unknown [3.92.225.197]) by ismtpd0074p1mdw1.sendgrid.net (SG) with ESMTP id FO1Sgfy2RiaF-L7fZFL5wA for ; Sun, 10 Nov 2019 10:20:39.449 +0000 (UTC) Date: Sun, 10 Nov 2019 10:20:39 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 71397 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16296 X-Redmine-Issue-Author: Dan0042 X-Redmine-Sender: Eregon 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?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr2rs+2CIptFkLgdbq5cXI?= =?us-ascii?Q?C6dLThoAlQkHyDnLB6Dg8OUsr8hxHl28TvjwkUI?= =?us-ascii?Q?nAwjp2F9xv6MDYoPX72gTmpqEQF2I5uDCFV4oEQ?= =?us-ascii?Q?uFQDL=2F+JU36+ZaWCsD8+bcSXvrrmPOUud9e+czz?= =?us-ascii?Q?Lh7oS+gf+YuhA9BSltr6TiaoBzvMakiTpcQ=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95772 Subject: [ruby-core:95772] [Ruby master Feature#16296] Alternative behavior for `...` in method body if `...` is not in method definition 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 #16296 has been updated by Eregon (Benoit Daloze). On current master `def m(a, ...); end` is a syntax error. So I think we need to confirm first whether we will allow any other parameter alongside `...`. ---------------------------------------- Feature #16296: Alternative behavior for `...` in method body if `...` is not in method definition https://bugs.ruby-lang.org/issues/16296#change-82591 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- In #16253 we settled on a syntax where the remainder arguments captured via `...` in the method definition can be forwarded via `...` in the method body. I think that was the correct decision. But I can't forget about the use case [presented by zverok](https://bugs.ruby-lang.org/issues/16253#note-6) (and in #15049) where the method definition is used to specify mandatory and default parameters and then forward all of them to another method. I've also experienced that same use case in my code. Using the current syntax we would need to do this: ```ruby def get(path:, accept: :json, headers: {}, ...) _request(method: :get, path: path, accept: accept, headers: headers, ...) end def post(path:, body:, accept: :json, headers: {}, ...) _request(method: :post, path: path, body: body, accept: accept, headers: headers, ...) end ``` Which feels pointlessly repetitive to me. So I was thinking that maybe if `...` is not present in the method definition, then in the method body `...` could take on the meaning of "all arguments of the method". Then the code would look like this: ```ruby def get(path:, accept: :json, headers: {}, **opts) _request(method: :get, ...) end def post(path:, body:, accept: :json, headers: {}, **opts) _request(method: :post, ...) end ``` In those examples (no positional parameters) it would also allow `Hash[...]` or `{}.replace(...)` to get the hash of all keyword arguments. Pro: it allows a new useful and powerful behavior Con: some may consider it 'unclean' to change the behavior of `...` based on the method definition -- https://bugs.ruby-lang.org/