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=AWL,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 5374A1F466 for ; Tue, 14 Jan 2020 10:11:49 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 81C50120A17; Tue, 14 Jan 2020 19:11:33 +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 386D5120A09 for ; Tue, 14 Jan 2020 19:11:29 +0900 (JST) Received: by filterdrecv-p3iad2-57f487d66-lptsx with SMTP id filterdrecv-p3iad2-57f487d66-lptsx-18-5E1D93D8-44 2020-01-14 10:11:36.922090827 +0000 UTC m=+2453098.058375772 Received: from herokuapp.com (unknown [54.163.208.32]) by ismtpd0002p1iad1.sendgrid.net (SG) with ESMTP id d0nP8ZpmSZWmDAE87F38Jg for ; Tue, 14 Jan 2020 10:11:36.792 +0000 (UTC) Date: Tue, 14 Jan 2020 10:11:36 +0000 (UTC) From: lars@greiz-reinsdorf.de Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 72509 X-Redmine-Project: ruby-master 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: =?us-ascii?Q?upJWHjv5luYHZAwiKbQRDznJrHGgIlpIB0ncpUjFDx3CbALn4L+9Fzg+n5dyLm?= =?us-ascii?Q?mzBteN63jKn1ddtT7x+bZqUdJm7HUqS3Wk8s3RQ?= =?us-ascii?Q?R86oA89tXc5VsVGOGPHM0CeRwIZWEnLkPuLG5F4?= =?us-ascii?Q?YFaHStoropBQhm3MRbGYNEqiq4SFeZ34X6WJc3j?= =?us-ascii?Q?GeDTUZz=2Ft7crVIc2tooG0CMlu3QccFje+k+0U=2FZ?= =?us-ascii?Q?MbhwTC4CcM4I17ivg=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 96846 Subject: [ruby-core:96846] [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 larskanis (Lars Kanis). Sorry for my late answer! I didn't get a notification mail. As noted above: 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 to `Proc#lambda?` . I therefore think it's kind of bug. Nevertheless your patch looks like a good alternative, which keeps backward compatibility and doesn't discard information when called as `proc.parameters(lambda:true)`. Would you still mind to merge it? ---------------------------------------- Feature #15357: Proc#parameters returns incomplete type information https://bugs.ruby-lang.org/issues/15357#change-83850 * 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/