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 BABEF1F609 for ; Wed, 28 Nov 2018 20:01:22 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id D7FAB120CD4; Thu, 29 Nov 2018 05:01:20 +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 528FC120C80 for ; Thu, 29 Nov 2018 05:01:18 +0900 (JST) Received: by filter0157p3mdw1.sendgrid.net with SMTP id filter0157p3mdw1-18201-5BFEF40A-3D 2018-11-28 20:01:14.570832092 +0000 UTC m=+1123344.902116217 Received: from herokuapp.com (ec2-54-144-20-158.compute-1.amazonaws.com [54.144.20.158]) by ismtpd0039p1iad1.sendgrid.net (SG) with ESMTP id KFQ7lAQSSs2CIZo4VhH74g for ; Wed, 28 Nov 2018 20:01:14.501 +0000 (UTC) Date: Wed, 28 Nov 2018 20:01:15 +0000 (UTC) From: lars@greiz-reinsdorf.de To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 65532 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15357 X-Redmine-Issue-Author: larskanis X-Redmine-Sender: larskanis 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS6pS75fkmJBzudJftzCpSJYrvccgT0cBWF8E5 KXfJOH6iBltCI5V97MVR+4WOFChVMWOV5IDYSrCyVclJc/GtupTTKFvUprAnOh3M5MRIug/qT9e3oW Pshg8F23xTCdtZRSX7eAqll4Npm8OoZrCyMtJ/RUZfMPPbpmH6++UsaKQQ== X-ML-Name: ruby-core X-Mail-Count: 90135 Subject: [ruby-core:90135] [Ruby trunk Bug#15357] Unify proc{} and lambda{}.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 #15357 has been reported by larskanis (Lars Kanis). ---------------------------------------- Bug #15357: Unify proc{} and lambda{}.parameters https://bugs.ruby-lang.org/issues/15357 * Author: larskanis (Lars Kanis) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-linux] * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- The current implementation of Proc#parameters [differentiate between lambda? true and false](https://github.com/ruby/ruby/blob/49cd16bfaf4f03885058ce748119bc8ea2de735a/iseq.c#L2800). This is presumably due to the fact, that [procs use tricks](https://ruby-doc.org/core-2.5.3/Proc.html#method-i-parameters) to apply arguments differently than lambda and methods. Unfortunately `proc{}.parameters` states all `:req` parameters as `:opt`, so that these both types of parameters are not distinguishable. This information loss leads to the situation that two different proc signatures return an equal parameters list, but behave differently: ```ruby pr = proc{|a,b=2| [a,b] } pr.parameters # => [[:opt, :a], [:opt, :b]] pr.call(:a) # => [:a, 2] # :a is interpret as the first parameter pr = proc{|a=1,b| [a,b] } pr.parameters # => [[:opt, :a], [:opt, :b]] pr.call(:a) # => [1, :a] # :a is interpret as the second parameter ``` That means that the current return values of `proc{}.parameters` are not suitable to build wrapper or proxy objects for a proc. In Eventbox I use the workaround to pass the proc to `define_method` and [query the method parameters instead](https://github.com/larskanis/eventbox/blob/3bcbc30096c6003e96d41c6496c781dfc90ac36a/lib/eventbox/argument_wrapper.rb#L10-L17). That way the list of parameters can be retrieved including `:req` and `:opt` differentiation, so that a wrapper proc can be built. The application of argument assignment tricks are a property of the Proc object, but not a property of single parameters. The property of the Proc object is already readable through `Proc#lambda?`, so that there's no need to apply this property to `Proc#parameters` as well. My proposal is to unify `proc{}.parameters` and `lambda{}.parameters`, so that `proc{}.parameters` returns `:req` arguments as well. -- https://bugs.ruby-lang.org/