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 1EBB11F462 for ; Fri, 26 Jul 2019 17:53:41 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id C8CEA120AE3; Sat, 27 Jul 2019 02:53:33 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id B7EA7120AF2 for ; Sat, 27 Jul 2019 02:53:29 +0900 (JST) Received: by filter0025p3iad2.sendgrid.net with SMTP id filter0025p3iad2-21662-5D3B3E18-2C 2019-07-26 17:53:28.924217701 +0000 UTC m=+9182.354666432 Received: from herokuapp.com (unknown [54.159.242.245]) by ismtpd0050p1mdw1.sendgrid.net (SG) with ESMTP id HDFoQ1z0TIm0Job62JczJQ for ; Fri, 26 Jul 2019 17:53:28.951 +0000 (UTC) Date: Fri, 26 Jul 2019 17:53:29 +0000 (UTC) From: daniel@dan42.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 69437 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15973 X-Redmine-Issue-Author: alanwu X-Redmine-Sender: Dan0042 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?8sy4RigFvRTdBfCVJrT9zb2J88PC92TMQwdNgaWYaq6jXSUyWcKUbtnIh75Ob3?= =?us-ascii?Q?=2FopKpDl0obu5SE+RYx9uONKWW2msdntWXACPw4S?= =?us-ascii?Q?fpK0AG7szHX1XWVPYBouI6yUBUv1dOB4pROmu6W?= =?us-ascii?Q?7xI=2F+0GTX6+znzRyydiZNdljjKDhRy9nQGE3w1=2F?= =?us-ascii?Q?BPQji7hicyUEUeHMHnGIUQtbP4gl+4R26bg=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 93935 Subject: [ruby-core:93935] [Ruby master Feature#15973] Make it so Kernel#lambda always return a lambda 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 #15973 has been updated by Dan0042 (Daniel DeLorme). I think the delegating lambda idea doesn't really work. I mean, it doesn't *do* anything. You just get a lambda that behaves like a proc. It just changes the return value of `Proc#lambda?` which I don't think has any benefit by itself. In fact it might be counterproductive to hide the fact that this Proc object really behaves like a proc and not a lambda. It seems the main use case for proc->lambda conversion is to validate the Proc defines the correct parameters? But I believe it's quite ok to let the writer of the Proc worry about that. And if you *really* want a lambda you should just enforce it. ```ruby def foo(lambda) lambda.lambda? or raise ArgumentError lambda.call(1,2,3) end foo -> (x) do 42 end #=> ArgumentError (wrong number of arguments (given 3, expected 1)) ``` So I haven't yet seen a single good use case for this conversion, and I can't think of one despite trying. You'd need a situation where you want a Proc to have either proc or lambda behavior based on a condition. That's.... On the other hand there's a good case to make for just letting the programmer do what s/he wants. If you want to convert a proc into a lambda presumably you have a reason for doing so, and understand the consequences. The only real danger is if a proc was converted to a lambda *inadvertently* . But I can't come up with a realistic situation where this could occur. All the "surprising" examples I've seen are contrived and in fact not surprising at all. If a method expects a proc and you give it a lambda, that's no different than giving it an Integer or any other object that fails expectations. I honestly can't think of a situation where you'd want `lambda(&myproc)` to just pass through the proc unchanged; if you don't want to convert you'd just use `myproc` directly, right? In the end it seems the only benefit of proc<->lambda conversion is for the sake of consistency of the `proc` and `lambda` methods? I guess that makes some sense, because this situation is definitely weird and surprising: ``` ruby lambda{ } #=> # class X;def lambda;super;end;end; X.new.lambda{ } #=> # lambda(&proc{ }) #=> # method(:lambda).call{ } #=> # def foo(&b);lambda(&b);end; foo{ } #=> # ``` ---------------------------------------- Feature #15973: Make it so Kernel#lambda always return a lambda https://bugs.ruby-lang.org/issues/15973#change-80091 * Author: alanwu (Alan Wu) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- When Kernel#lambda receives a Proc that is not a lambda, it returns it without modification. l propose changing `Kernel#lambda` so it always returns a lambda. Calling a method called lambda and having it effective do nothing was not very intuitive. https://github.com/ruby/ruby/pull/2262 Judging from marcandre's investigation here: https://bugs.ruby-lang.org/issues/15620#note-1 changing the behavior should not cause much breakage, if any. This also happens to fix [Bug #15620] -- https://bugs.ruby-lang.org/