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.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,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 7321C1F461 for ; Wed, 28 Aug 2019 02:13:05 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 4B876120A4D; Wed, 28 Aug 2019 11:12:57 +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 2798E120861 for ; Wed, 28 Aug 2019 11:12:54 +0900 (JST) Received: by filter0118p3las1.sendgrid.net with SMTP id filter0118p3las1-20163-5D65E327-3C 2019-08-28 02:12:55.902610497 +0000 UTC m=+106679.889710983 Received: from herokuapp.com (unknown [3.92.60.47]) by ismtpd0023p1mdw1.sendgrid.net (SG) with ESMTP id HmNNxODVRkO2JDXtIbDrow for ; Wed, 28 Aug 2019 02:12:55.783 +0000 (UTC) Date: Wed, 28 Aug 2019 02:12:55 +0000 (UTC) From: merch-redmine@jeremyevans.net Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 70178 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15357 X-Redmine-Issue-Author: larskanis X-Redmine-Sender: jeremyevans0 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?RVE3t853K5scBhbmJHUzZTFFeVC=2FZSUmHZ0Dc+26wcEi2CTgsF1oz0wTSSxGGN?= =?us-ascii?Q?BIEyU+YuRSZFm9w91lQVH5hNJL3ciEoXIJlAfjr?= =?us-ascii?Q?xNil39nYhEDaf67RShu7zY4FKL2lX1nBPP=2FN4RK?= =?us-ascii?Q?CGMhETlGFLTou0Do4ORJqk17GE7fcgGrnroguV+?= =?us-ascii?Q?TLy76TEs4nLWcAL8QVIte6mPB7MAY4KyFhA=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 94625 Subject: [ruby-core:94625] [Ruby master Feature#15357] Proc#parameters returns incomplete type information 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 updated by jeremyevans0 (Jeremy Evans). Backport deleted (2.4: UNKNOWN, 2.5: UNKNOWN) ruby -v deleted (ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-linux]) Tracker changed from Bug to Feature File proc-parameters-req-15357.patch added I don't think the current behavior is a bug, as the parameters for a non-lambda proc are optional. Also, changing the behavior could be backwards incompatible. I propose instead a `lambda` keyword to `Proc#parameters`, which would return the parameters as if the proc were a lambda. Attached is a patch that implements this. ---------------------------------------- Feature #15357: Proc#parameters returns incomplete type information https://bugs.ruby-lang.org/issues/15357#change-81217 * Author: larskanis (Lars Kanis) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- 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 a workaround is used: The proc is passed to `define_method` and the [method parameters are retrieved 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 is a property of the Proc object - not a property of single parameters. Therefore it shouldn't be applied to `Proc#parameters` in addition - at least not in a way that discards valuable information. 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` shows positional arguments without default value as type `:req` as well. ---Files-------------------------------- proc-parameters-req-15357.patch (5.15 KB) -- https://bugs.ruby-lang.org/