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=-4.0 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 55E2D1F461 for ; Mon, 8 Jul 2019 00:20:35 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id A347E1208FA; Mon, 8 Jul 2019 09:20:28 +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 D7F4612082F for ; Mon, 8 Jul 2019 09:20:26 +0900 (JST) Received: by filter0100p3las1.sendgrid.net with SMTP id filter0100p3las1-14200-5D228C4C-10 2019-07-08 00:20:28.364692922 +0000 UTC m=+361392.212820575 Received: from herokuapp.com (unknown [35.175.150.18]) by ismtpd0010p1iad2.sendgrid.net (SG) with ESMTP id NTzuhUs5Tieiwaxdfx-xHA for ; Mon, 08 Jul 2019 00:20:28.193 +0000 (UTC) Date: Mon, 08 Jul 2019 00:20:28 +0000 (UTC) From: XrXr@users.noreply.github.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 69091 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15973 X-Redmine-Issue-Author: alanwu X-Redmine-Sender: alanwu 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?PWg67P6owy8ojUUZg1G=2FQM4Z0jTQ2XLCqLM8Y2L8tUvRFuUPM6+aKANjRFY5CJ?= =?us-ascii?Q?rIvNzJh4jNusXDPQm9M+FiIi=2F9ULGOFRDMovMH8?= =?us-ascii?Q?qrY+=2FQppeUZ2+VMi7bhBpeHUwaUgPuSdWu8qZ6M?= =?us-ascii?Q?H=2F0ih=2FZT7E4Gronfep=2FO17LTC6wWRyhcdpy2uPB?= =?us-ascii?Q?jvyhGDQvIdqCWMiVB6X8OQ5yMtto+qxkOxQ=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 93597 Subject: [ruby-core:93597] [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 alanwu (Alan Wu). The 2.4 spec is a bit problematic since it makes it impossible to forward a block to `Kernel#lambda` with a block pass. In the rest of the language forwarding a block has no effect on semantics compared to passing one literally. The idea of literal blocks being different from non-literal ones exists _only_ in the case of `Kernel#lambda`. A concept at odds with the rest of the language specific to one single method is sure to surprise. Special one-off concepts make the language harder to learn and add complications to implementaitons. As others have pointed out, it's already possible to transform a proc into a lambda-proc via `define_method`. My proposal isn't adding anything new with regards to messing with the perscribed usage of code within blocks. Transforming a proc into a lambda-proc is certainly a sharp tool. For me it falls in the same category as `instance_variable_set` and `const_set`. However, I think the situation in which it ends up being surprinsg is very rare. `return` within a `Proc.new do ...` comes up rarely as is. Is "someone might misuse this in specific sutations" a good reason to keep an ad-hoc concept in the language? For me, no. ---------------------------------------- Feature #15973: Make it so Kernel#lambda always return a lambda https://bugs.ruby-lang.org/issues/15973#change-79189 * 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/