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=-4.1 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, 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 23E261F453 for ; Mon, 4 Feb 2019 18:25:15 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 8FE16121AAA; Tue, 5 Feb 2019 03:25:11 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 3A228121953 for ; Tue, 5 Feb 2019 03:25:07 +0900 (JST) Received: by filter0103p3iad2.sendgrid.net with SMTP id filter0103p3iad2-28883-5C588380-26 2019-02-04 18:25:04.511756096 +0000 UTC m=+172001.876239534 Received: from herokuapp.com (ec2-50-17-25-138.compute-1.amazonaws.com [50.17.25.138]) by ismtpd0025p1iad2.sendgrid.net (SG) with ESMTP id QIZRJE4cSXykA6mgxU6cmQ for ; Mon, 04 Feb 2019 18:25:04.606 +0000 (UTC) Date: Mon, 04 Feb 2019 18:25:05 +0000 (UTC) From: ruby-core@marc-andre.ca To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 66849 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15574 X-Redmine-Issue-Author: ko1 X-Redmine-Issue-Assignee: matz X-Redmine-Sender: marcandre 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: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS5/m1JyzVG8iKCQG7w0IXZTwkT1+qWIOqmDxP YrORQyL67s+ykenr1V1kMGCrrS6ABHwgg6rJ71MBsOBDk9SWlDei7NohL6iOfjXVC5a+gDFFOHmeEf QU434G2eIETPQOwx95X9/41C17sCzk/l8vxRCbDM+QyDIlm1VhPzXdeRTw== X-ML-Name: ruby-core X-Mail-Count: 91394 Subject: [ruby-core:91394] [Ruby trunk Feature#15574] Prohibit to pass a block on super() implicitly 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 #15574 has been updated by marcandre (Marc-Andre Lafortune). I agree with Eregon that it would be a compatibility nightmare. Moreover I rather like this quirk. Is there an actual use case for thinking about removing it (besides it being quirky)? I would bet that there are way more methods calling super with the block intact than the reverse. I will frequently prepend a method that intercepts a parameter, for example, deals with it and call `super` with the rest: ``` ruby def foo(*args, **options, extra_opt: nil) puts "extra!" if extra_opt super(*args, **options) end ``` I don't recall passing a different (or no) block to `super`, but my memory isn't very good ;-) In short, I'm against this proposal. ---------------------------------------- Feature #15574: Prohibit to pass a block on super() implicitly https://bugs.ruby-lang.org/issues/15574#change-76651 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) * Target version: ---------------------------------------- As described in [Feature #15554], `super()` (not `super`) pass the given block. ``` class C def foo p block_given? end end class C1 < C def foo super #=> true super() #=> true end end C1.new.foo{} ``` `super` (without parameters) passes all passed parameters so it is no surprise to pass given block. However, `super()` (with parameters. In this case, it passes 0 parameters) also pass given block implicitly. I'm not sure who use this behavior, but I think it is simple to prohibit such implicit block passing. -- https://bugs.ruby-lang.org/