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.8 required=3.0 tests=AWL,BAYES_00, 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 1FCF01F770 for ; Tue, 1 Jan 2019 11:09:35 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 01DF012164C; Tue, 1 Jan 2019 20:09:32 +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 7D58F121039 for ; Tue, 1 Jan 2019 20:09:29 +0900 (JST) Received: by filter0043p3mdw1.sendgrid.net with SMTP id filter0043p3mdw1-32519-5C2B4A66-27 2019-01-01 11:09:26.440112647 +0000 UTC m=+995908.092383455 Received: from herokuapp.com (ec2-54-211-244-225.compute-1.amazonaws.com [54.211.244.225]) by ismtpd0018p1iad2.sendgrid.net (SG) with ESMTP id 9G2LlFCmQKyrauIkmFjUEw Tue, 01 Jan 2019 11:09:26.364 +0000 (UTC) Date: Tue, 01 Jan 2019 11:09:27 +0000 (UTC) From: mame@ruby-lang.org To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 66264 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15477 X-Redmine-Issue-Author: robb X-Redmine-Sender: mame 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/Ymy4QrNMhiuLXJG8OTL2vJD1yS6D+jKAfLMBwe33UqfKfC50/X1M5XUCK/Z4FF FKils3nMeq+HswfnGb7GXY1ztu8GKjEN6OmYIjDMgbWMKvRiQIVij4kUMeuLgFiFergD7hAGIvzVM6 F6joodD0BI3AuUiQIWPAXiZKDNVniT2/TGJkr8qGI8Ia+7DChcpxdYvlwg== X-ML-Name: ruby-core X-Mail-Count: 90842 Subject: [ruby-core:90842] [Ruby trunk Feature#15477] Proc#arity returns -1 for composed lambda Procs of known arguments 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 #15477 has been updated by mame (Yusuke Endoh). Tracker changed from Bug to Feature ruby -v deleted (ruby 2.6.0p0 (2018-12-25 revision 66547) [x86_64-linux]) Backport deleted (2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN) Looks not a bug to me. Moving to the feature tracker. A patch is attached. ```diff diff --git a/proc.c b/proc.c index c09e845ec0..45e2a21551 100644 --- a/proc.c +++ b/proc.c @@ -3063,6 +3063,16 @@ compose(VALUE dummy, VALUE args, int argc, VALUE *argv, VALUE passed_proc) return rb_funcallv(f, idCall, 1, &fargs); } +static VALUE +compose_proc_new(VALUE procs) +{ + VALUE first_proc = RARRAY_AREF(procs, 1); + int max_arity, min_arity = rb_proc_min_max_arity(first_proc, &max_arity); + int lambda_p = rb_proc_lambda_p(first_proc); + struct vm_ifunc *ifunc = rb_vm_ifunc_new((rb_block_call_func_t) compose, (void *)procs, min_arity, max_arity); + return cfunc_proc_new(rb_cProc, (VALUE)ifunc, lambda_p); +} + /* * call-seq: * prc << g -> a_proc @@ -3089,7 +3099,7 @@ proc_compose_to_left(VALUE self, VALUE g) GetProcPtr(self, procp); is_lambda = procp->is_lambda; - proc = rb_proc_new(compose, args); + proc = compose_proc_new(args); GetProcPtr(proc, procp); procp->is_lambda = is_lambda; @@ -3122,7 +3132,7 @@ proc_compose_to_right(VALUE self, VALUE g) GetProcPtr(self, procp); is_lambda = procp->is_lambda; - proc = rb_proc_new(compose, args); + proc = compose_proc_new(args); GetProcPtr(proc, procp); procp->is_lambda = is_lambda; ``` ---------------------------------------- Feature #15477: Proc#arity returns -1 for composed lambda Procs of known arguments https://bugs.ruby-lang.org/issues/15477#change-76031 * Author: robb (Robb Shecter) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- ``` f = -> x { x + 2 } g = -> x { x * 2 } h = f << g f.arity # => 1 g.arity # => 1 h.arity # => -1 THIS SHOULD BE 1 because h "knows" that it takes exactly 1 argument: h.call # => ArgumentError (given 0, expected 1) ``` Lambda Procs which are composed using `<<` seem to partially lose knowledge of their arity. I don't know if this affects other procs, or the `>>` operator as well. The Proc#arity docs state that -1 is returned only when a variable or unknown number of arguments are expected by the Proc. But here, that's not the case. -- https://bugs.ruby-lang.org/