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.3 required=3.0 tests=AWL,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 690061F453 for ; Tue, 5 Feb 2019 02:03:12 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 8223F1216B5; Tue, 5 Feb 2019 11:03: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 E5DB3121544 for ; Tue, 5 Feb 2019 11:03:00 +0900 (JST) Received: by filter0072p3las1.sendgrid.net with SMTP id filter0072p3las1-27365-5C58EECF-2D 2019-02-05 02:02:55.879054516 +0000 UTC m=+200265.257809795 Received: from herokuapp.com (ec2-50-17-25-138.compute-1.amazonaws.com [50.17.25.138]) by ismtpd0036p1mdw1.sendgrid.net (SG) with ESMTP id J3MbQ0AKQf-SzBPyFQnpDQ for ; Tue, 05 Feb 2019 02:02:55.756 +0000 (UTC) Date: Tue, 05 Feb 2019 02:02:57 +0000 (UTC) From: ko1@atdot.net To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 66857 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15574 X-Redmine-Issue-Author: ko1 X-Redmine-Issue-Assignee: matz X-Redmine-Sender: ko1 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS4wx/Jbem1YXzYg1/PbolmUwmjyMe1KyRD7cT 3yYoMAhW8TDZp7Y0I3F7y2RAzpMicLMy6oQ1EdUAopb1ywMgnNHimapOOuqzqigHRCVIPoy66YdsmA vpJrkUIowEQYNxAUpx4syNbMu58UgnIvu8n1 X-ML-Name: ruby-core X-Mail-Count: 91402 Subject: [ruby-core:91402] [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 ko1 (Koichi Sasada). marcandre (Marc-Andre Lafortune) wrote: > Is there an actual use case for thinking about removing it (besides it being quirky)? I assume this spec is because of historical reason. Block parameter is introduced ruby-1.1b9_01, but maybe Matz wanted to pass block to initialize method (it's my speculation). Exceptional rule is difficult to learn, so if we have no reason to keep compatibility, I want to remove this exceptional rule. > 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 want to clarify this spec is desired or not. Why don't you pass a block parameter explicitly? Because you know the spec and intentional, or simply forget to pass it (and working it with this spec fortunately)? ---------------------------------------- Feature #15574: Prohibit to pass a block on super() implicitly https://bugs.ruby-lang.org/issues/15574#change-76658 * 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/