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.7 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 021EE1F466 for ; Tue, 14 Jan 2020 13:21:53 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id D5C3D120A95; Tue, 14 Jan 2020 22:21:33 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 54C2B120A93 for ; Tue, 14 Jan 2020 22:21:31 +0900 (JST) Received: by filterdrecv-p3mdw1-56c97568b5-zwhxv with SMTP id filterdrecv-p3mdw1-56c97568b5-zwhxv-19-5E1DC05F-52 2020-01-14 13:21:35.841162817 +0000 UTC m=+2464708.738855473 Received: from herokuapp.com (unknown [54.163.208.32]) by ismtpd0089p1mdw1.sendgrid.net (SG) with ESMTP id vwvAki50Ru2ncOIN1EH3gg for ; Tue, 14 Jan 2020 13:21:35.818 +0000 (UTC) Date: Tue, 14 Jan 2020 13:21:35 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 72518 X-Redmine-Project: ruby-master X-Redmine-Issue-Id: 15357 X-Redmine-Issue-Author: larskanis 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?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr18uJE2Kbh6QMteqQCos2?= =?us-ascii?Q?hJyb6f7k4AycJUBApluH6jqL85aajkQ715Fmwdk?= =?us-ascii?Q?Eskf9TBvetzUc5Z5u=2FdNpgsOZf2bSHw8rZfQ5Lg?= =?us-ascii?Q?tNlerVIVTp9WclRdmZRZE27gOkudCQLF0gioYuc?= =?us-ascii?Q?uyeOEtpi0YpWGUKmDsLuetCKxkBMFtvKmGGiL=2Fe?= =?us-ascii?Q?CZOtQxpj2vTBxcJhY=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 96855 Subject: [ruby-core:96855] [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 Eregon (Benoit Daloze). I agree, and discussed that a bit in #16499. I think Proc#parameters should expose source-level information, not interpret it according to Kernel#lambda?. ---------------------------------------- Feature #15357: Proc#parameters returns incomplete type information https://bugs.ruby-lang.org/issues/15357#change-83865 * 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/