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=-2.6 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_HELO_NONE,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 441211F463 for ; Wed, 27 Nov 2019 17:55:17 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 7F7CA1208FC; Thu, 28 Nov 2019 02:55:04 +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 AA52A1208F9 for ; Thu, 28 Nov 2019 02:55:01 +0900 (JST) Received: by filter0080p3mdw1.sendgrid.net with SMTP id filter0080p3mdw1-29356-5DDEB878-1E 2019-11-27 17:55:04.682571373 +0000 UTC m=+669684.155873581 Received: from herokuapp.com (unknown [3.87.7.191]) by ismtpd0055p1iad1.sendgrid.net (SG) with ESMTP id SiYQgtFsTEieWQD43k7oAA for ; Wed, 27 Nov 2019 17:55:04.556 +0000 (UTC) Date: Wed, 27 Nov 2019 17:55:04 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 71631 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16166 X-Redmine-Issue-Author: sawa X-Redmine-Sender: Eregon 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?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr2Z56GBhLYRZ4Q++WEEXT?= =?us-ascii?Q?eYEXtR5L=2FT5VKI0Llgj9TVzHC=2FO9OPvktICEoy1?= =?us-ascii?Q?h4tn2pRlnQE1HJgijFZunYMiS=2FrEpEu4WuwsSk1?= =?us-ascii?Q?Vo05FyysoU9lf0uX1XfKHpUYra3L9Z=2FLVySExfW?= =?us-ascii?Q?wR4IZGe=2FjOfzGLT0HyhEW1VKgH455BihTkA=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95996 Subject: [ruby-core:95996] [Ruby master Feature#16166] Remove exceptional treatment of *foo when it is the sole block parameter 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 #16166 has been updated by Eregon (Benoit Daloze). @sawa wrote this in the dev-meeting ticket: > Unintended arity. This must be fixed in an earlier stage before Ruby 3. I think matz conclusion is all behavior shown in this bug so far is intended, except for `*foo, **bar`. @Dan0042 ``` proc{ |a,b| [a,b] }.call(1,2) #=> [1, 2] proc{ |*ab| ab }.call(1,2) #=> [1, 2] proc{ |a,b| [a,b] }.call([1,2]) #=> [1, 2] proc{ |*ab| ab }.call([1,2]) #=> [[1, 2]] ``` That's just how Proc works, multiple parameters will splat an Array if a single Array argument is given. I think long-term we might want to use lambda semantics by default for blocks, which doesn't have that splatting magic. ---------------------------------------- Feature #16166: Remove exceptional treatment of *foo when it is the sole block parameter https://bugs.ruby-lang.org/issues/16166#change-82832 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- In the parameter signature of a code block for a method that is not involved in method definition or creation of lambda objects, two types of arguments `["a"]` and `"a"` are neutralized: ```ruby instance_exec(["a"]){|foo, bar| foo} # => "a" instance_exec("a"){|foo, bar| foo} # => "a" instance_exec(["a"]){|*foo, **bar| foo} # => ["a"] instance_exec("a"){|*foo, **bar| foo} # => ["a"] ``` This is the same behavior as with assignment constructions: ```ruby foo, bar = ["a"]; foo # => "a" foo, bar = "a"; foo # => "a" *foo = ["a"]; foo # => ["a"] *foo = "a"; foo # => ["a"] ``` And it contrasts with constructions involved in method definition or creation of lambda objects, where the distinction is preserved: ```ruby lambda{|foo| foo}.call(["a"]) # => ["a"] lambda{|foo| foo}.call("a") # => "a" ->(foo){foo}.call(["a"]) # => ["a"] ->(foo){foo}.call("a") # => "a" lambda{|*foo| foo}.call(["a"]) # => [["a"]] lambda{|*foo| foo}.call("a") # => ["a"] ->(*foo){foo}.call(["a"]) # => [["a"]] ->(*foo){foo}.call("a") # => ["a"] ``` However, when `*foo` is the sole parameter of a code block for a method that is not involved in method definition or creation of lambda objects, `["a"]` and `"a"` are not neutralized: ```ruby instance_exec(["a"]){|*foo| foo} # => [["a"]] instance_exec("a"){|*foo| foo} # => ["a"] ``` behaving in contrast to assignment constructions, and rather on a par with constructions involved in method definition or creation of lambda objects. Particularly, existence or absence of another parameter `**bar` entirely changes what `foo` refers to: ```ruby instance_exec(["a"]){|*foo| foo} # => [["a"]] instance_exec(["a"]){|*foo, **bar| foo} # => ["a"] ``` I find this behavior inconsistent and confusing. I would like to request to remove this exceptional treatment of splatted parameter `*foo` when it is the sole parameter in a code block. I request this behavior: ```ruby instance_exec(["a"]){|*foo| foo} # => ["a"] ``` -- https://bugs.ruby-lang.org/