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 662451F463 for ; Wed, 25 Dec 2019 11:13:09 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 271EB120937; Wed, 25 Dec 2019 20: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 95FA8120935 for ; Wed, 25 Dec 2019 20:12:54 +0900 (JST) Received: by filterdrecv-p3las1-5bf99c48d-qbhn7 with SMTP id filterdrecv-p3las1-5bf99c48d-qbhn7-19-5E03443C-35 2019-12-25 11:13:00.868363104 +0000 UTC m=+728831.445380131 Received: from herokuapp.com (unknown [3.83.106.33]) by ismtpd0001p1iad2.sendgrid.net (SG) with ESMTP id wmrE5ZoiTPGKHYmc11xJnA for ; Wed, 25 Dec 2019 11:13:00.740 +0000 (UTC) Date: Wed, 25 Dec 2019 11:13:00 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 72123 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15973 X-Redmine-Issue-Author: alanwu X-Redmine-Issue-Assignee: matz 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?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr28XO2cYeTTxbvO26PZns?= =?us-ascii?Q?FMZIwDKApGEIHj5etaabzZ3Wqpp+K8cHacrHHoi?= =?us-ascii?Q?kf2ZIDqhOJdpTqE5EL3WkYEvnCYyd0TjRffhPf8?= =?us-ascii?Q?adW796VhBWcrzc6VhzL5hhVMtdfzYG0iZ=2FuN7ah?= =?us-ascii?Q?X=2FhbWoNEPNchXyGqwCexH9agNXfNVs7h6Hnl1da?= =?us-ascii?Q?geG5RCii989uEtesY=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 96464 Subject: [ruby-core:96464] [Ruby master Feature#15973] Let 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 Eregon (Benoit Daloze). ko1 (Koichi Sasada) wrote: > more aggressive proposal is obsolete `lambda` call, and use `->` (maybe it is too aggressive). Sounds even better to me, but I guess that might be disruptive for everyone to adopt `-> {}` style. It would be interesting to see what matz thinks about this. `->` exists since at least 2.0, so it shouldn't be a compatibility issue to use it. >From the point of view of a Ruby VM, not having to handle `#lambda` magically changing the semantics of the passed block would be great, because it's really awkward and hard to check if the block is literal or not (considering `lambda` can be `alias`-ed). It would also simplify the semantics for the user: `method_call { ... }` is always a non-lambda Proc, and `-> {}` is the only way for a lambda. ---------------------------------------- Feature #15973: Let Kernel#lambda always return a lambda https://bugs.ruby-lang.org/issues/15973#change-83392 * Author: alanwu (Alan Wu) * Status: Assigned * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) * Target version: 2.8 ---------------------------------------- When Kernel#lambda receives a Proc that is not a lambda, it returns it without modification. l propose to change `Kernel#lambda` so it always returns a lambda. Calling a method called lambda and having it do nothing in effect is 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/