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.0 required=3.0 tests=AWL,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_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 B38E11F609 for ; Wed, 28 Nov 2018 11:06:02 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 8C417121418; Wed, 28 Nov 2018 20:06:01 +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 CEF2C121415 for ; Wed, 28 Nov 2018 20:05:59 +0900 (JST) Received: by filter0083p3iad2.sendgrid.net with SMTP id filter0083p3iad2-25927-5BFE7694-4B 2018-11-28 11:05:56.785297484 +0000 UTC m=+499686.499231814 Received: from herokuapp.com (ec2-54-144-20-158.compute-1.amazonaws.com [54.144.20.158]) by ismtpd0033p1iad2.sendgrid.net (SG) with ESMTP id ls7iGeXPQQyst-0PN7a9mg for ; Wed, 28 Nov 2018 11:05:56.761 +0000 (UTC) Date: Wed, 28 Nov 2018 11:05:57 +0000 (UTC) From: shevegen@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 65511 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15352 X-Redmine-Issue-Author: gfx X-Redmine-Sender: shevegen 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS7pcGHktCzfaWhhcVQCPCukfeQ2k9vN8Xz8kV 8h9YXrGaGcwgHSBwfidbcSCb/u7Til9TzdSz1Ohha+qfD8qcusnngiha1zOZv8zC+LLR8vOGdrSj2U oxMZcAImTzqlX+DPGTwLHE6PnrSuNWV9TzQ3MQk1owUxm1RGD9sl72r68A== X-ML-Name: ruby-core X-Mail-Count: 90116 Subject: [ruby-core:90116] [Ruby trunk Feature#15352] Mandatory block parameters 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 #15352 has been updated by shevegen (Robert A. Heiler). This is an interesting suggestion in the sense that block parameters, or rather, blocks as a whole, are a bit like additional arguments to every method in ruby, at all times, optional; but they are also quite special entities in ruby. For example, to use .call on a proc; is a bit similar to yield, and unbinding/rebinding a method and passing this as a block to another method. Typically if we have a method such as foo(), in ruby we can call it via: foo() foo foo { :something } All three ways are more or less the same, except for the last which pushes more information onto the method foo; but that information may not be evaluated within the method body (of foo). I think this is where matz should come in since he designed ruby and added blocks, so he knows best how blocks are seen (from within ruby itself). I could see it go either way with statements, where ruby users may say that block parameters should behave like regular parameters of methods; or that blocks are special and so block parameters should also be special. I myself have no real preference either way. I think backwards compatibility and backwards behaviour may be a reason in retaining the present behaviour, though; but again, I am neutral on the feature suggestion in itself. We can also reason that this would allow for more functionality, since he would gain the ability to cause blocks to raise an error, in this case an ArgumentError. There is, however had, one part I slightly dislike, and that is the syntax. I don't have an alternative suggestion, which is bad, but I don't like the close associoated of &! there. Perhaps my opinion is partially affected by other unrelated suggestions, e. g. to add arguments to &: invocation styles, such as &.: or variants that use even more characters. But anyway, I guess the syntax is partially separate from the suggested functionality, so I think it may be best to ask matz about the principle situation first, that is whether block arguments should/could behave like regular methods too (specifically whether they should be able to raise ArgumentError, if a ruby user wants to have it that way). One last point; not sure if they are worth mentioning but I will mention it, if only for symmetry: - In regular parameters signature we have something like: def foo(bar = '') def foo(bar) In the second case we must supply an argument; in the first, the default will be to an empty String ''. I understand that this can not be the same for blocks, at the least not without changing how they behave, but I wanted to point this out because to me this is quite different in behaviour and syntax, from the proposed &! or any similar proposal - I guess it all has to be different to the two method definitions above. Anyway, I wanted to write a bit more, but I tend to write too much so I will stop here. ---------------------------------------- Feature #15352: Mandatory block parameters https://bugs.ruby-lang.org/issues/15352#change-75236 * Author: gfx (Goro FUJI) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- There are too many block parameter assertions (it's kind of idioms: [`raise NoBlockGiven unless glock_given?`](https://github.com/search?q=raise+NoBlockGiven+unless+block_given&type=Code)). It's very useful if there's a syntax to declare mandatory block parameters, such as: ```ruby def foo(&!block) block.call end foo() # raises ArgumentError "in `foo`: no block given" ``` -- https://bugs.ruby-lang.org/