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 800841F454 for ; Sun, 10 Nov 2019 21:41:13 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 5DFD112097E; Mon, 11 Nov 2019 06:41:03 +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 A1C1212097D for ; Mon, 11 Nov 2019 06:41:00 +0900 (JST) Received: by filter0122p3las1.sendgrid.net with SMTP id filter0122p3las1-5635-5DC883EE-3A 2019-11-10 21:41:02.925276118 +0000 UTC m=+258911.369006386 Received: from herokuapp.com (unknown [3.92.225.197]) by ismtpd0051p1iad1.sendgrid.net (SG) with ESMTP id 003rirt_S8WbuvJ0TQ0lkQ for ; Sun, 10 Nov 2019 21:41:02.609 +0000 (UTC) Date: Sun, 10 Nov 2019 21:41:02 +0000 (UTC) From: merch-redmine@jeremyevans.net Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 71404 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16253 X-Redmine-Issue-Author: Dan0042 X-Redmine-Sender: jeremyevans0 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?RVE3t853K5scBhbmJHUzZTFFeVC=2FZSUmHZ0Dc+26wcEi2CTgsF1oz0wTSSxGGN?= =?us-ascii?Q?BICPVKicc6lUWxP40jAosdepA=2FL40UnewebFtjs?= =?us-ascii?Q?vdJ4RI342VlhbzRZMfkgdo5onmDZvHkDwOCJqAq?= =?us-ascii?Q?aIzmhvhSKbj7Y4teMB52CuAflEd1cRNUnudmhME?= =?us-ascii?Q?fL1fH6uRA9KrvVtxJSh+L9o6lqg4=2FoQKD3w=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95779 Subject: [ruby-core:95779] [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 jeremyevans0 (Jeremy Evans). Eregon (Benoit Daloze) wrote: > Is it intentional that this ticket was closed but `def m(meth, ...)` is a SyntaxError? This is expected at present. Lead argument handling will probably happen in the future. From the notes of the last dev meeting: ``` Future work: lead argument handling is postponed * lead arguments can be extracted * lead arguments can be added * def f(x, y, ...); g(1, 2, ...); end ``` It is true that this means the syntax only handles a subset of delegation methods. You can always do things the longer way if you need more control: ```ruby ruby2_keywords def method_missing(name, *args) if name.to_s.end_with?('=') update(name, *args) else # ... end end ``` ---------------------------------------- Feature #16253: Shorthand "forward everything" syntax https://bugs.ruby-lang.org/issues/16253#change-82603 * 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/