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.9 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 CC9FC1F4C0 for ; Sat, 19 Oct 2019 02:56:49 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 1F657120A83; Sat, 19 Oct 2019 11:56:39 +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 1262B120A6B for ; Sat, 19 Oct 2019 11:56:36 +0900 (JST) Received: by filter0031p3iad2.sendgrid.net with SMTP id filter0031p3iad2-10622-5DAA7B65-44 2019-10-19 02:56:37.637830899 +0000 UTC m=+93973.862750951 Received: from herokuapp.com (unknown [54.89.20.137]) by ismtpd0052p1iad2.sendgrid.net (SG) with ESMTP id kK8XnUIAT_WdeOX2NxanCw for ; Sat, 19 Oct 2019 02:56:37.624 +0000 (UTC) Date: Sat, 19 Oct 2019 02:56:37 +0000 (UTC) From: samuel@oriontransfer.net Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 71019 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16253 X-Redmine-Issue-Author: Dan0042 X-Redmine-Sender: ioquatix 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?cjxb6GWHefMLoR50bkJBcGo6DRiDl=2FNYcMZdY+Wj30TT3++bLEbTu8etA1xvN=2F?= =?us-ascii?Q?ZMo0n1zvpErZqUpgoc8exicBd+UtjSTZJdha9LY?= =?us-ascii?Q?h74R1aNT1Q7cNvZ=2Ft5kUCjTv93aliYYsF0bqBcn?= =?us-ascii?Q?XOBGEdsRVaDZgvWHlOF4Gp0UzDuaa1reNVv1ce8?= =?us-ascii?Q?lwP86qTtryndZutKaiTisvyM55=2FAkFfrJ8w=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95428 Subject: [ruby-core:95428] [Ruby master Feature#16253] Shorthand "forward everything" syntax 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 #16253 has been updated by ioquatix (Samuel Williams). The reason to support `...` with other args is something like this: ``` class Controller < Container::Controller def initialize(command, *arguments, **options, &block) @command = command super(*arguments, **options, &block) end end # Nicer? class Controller < Container::Controller def initialize(command, ...) @command = command super(...) end end ``` I think `...` should be remainder of arguments that aren't explicitly consumed. Semantics might be a little bit more tricky to implement, but it makes a lot of sense to me and there are *many* places where such a syntax would make things not only clearer, but also faster by eliding allocations for `*arguments` and `**options`. ---------------------------------------- Feature #16253: Shorthand "forward everything" syntax https://bugs.ruby-lang.org/issues/16253#change-82182 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- What about using this: ```ruby def foo(*) @bar.foo(*) ``` to mean this: ```ruby def foo(*a, **o, &b) @bar.foo(*a, **o, &b) ``` I used `def foo(*)` because that's currently valid ruby code, but I'm fine with any syntax. It's like the no-parentheses `super` shorthand, but for any method. It makes it easier to write correct forwarding code. If rubyists must be told they have to change their forwarding code in 2.7 (due to keyword arguments), the pill might be easier to swallow if the change is a reduction rather than an increase in verbosity. And we'd even be future-proof if an eventual FOURTH kind of parameter is introduced!!!! -- https://bugs.ruby-lang.org/