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-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,UNPARSEABLE_RELAY 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 4AA921F990 for ; Thu, 6 Aug 2020 19:10:03 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id E6AC3120ACF; Fri, 7 Aug 2020 04:09:23 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 8FC70120A36 for ; Fri, 7 Aug 2020 04:09:21 +0900 (JST) Received: by filterdrecv-p3mdw1-7ff865655c-r62j4 with SMTP id filterdrecv-p3mdw1-7ff865655c-r62j4-19-5F2C5578-58 2020-08-06 19:09:44.751854018 +0000 UTC m=+694405.429517037 Received: from herokuapp.com (unknown) by ismtpd0023p1iad2.sendgrid.net (SG) with ESMTP id bcwyDMpnT1KalXAXod8MMA for ; Thu, 06 Aug 2020 19:09:44.666 +0000 (UTC) Date: Thu, 06 Aug 2020 19:09:44 +0000 (UTC) From: daniel@dan42.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 75330 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 17105 X-Redmine-Issue-Author: Eregon 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?8sy4RigFvRTdBfCVJrT9zb2J88PC92TMQwdNgaWYaq52VZoPGk5+oRVH+fd2vr?= =?us-ascii?Q?8HeG2JSigHXV2838B2YLj6AnQCcNorxqKXo1YRN?= =?us-ascii?Q?oW8GJ9DsqjOfozyDY4e=2FX4yf4SzF28X7m9Wmy7E?= =?us-ascii?Q?ShGGf782VUQIHsaS4NTCrRVak6PF0K8iDcWpXU0?= =?us-ascii?Q?=2FaTW8a6V+mjNwhd5IKIrAq1vcN1ie8W9rzKiwuR?= =?us-ascii?Q?MrFdsUXyAX4nq13xo=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 99504 Subject: [ruby-core:99504] [Ruby master Bug#17105] A single `return` can return to two different places in a proc inside a lambda inside a method 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 #17105 has been updated by Dan0042 (Daniel DeLorme). I think the behavior makes sense to some extent, because the proc is within 2 nested contexts. Since the proc is within the lambda context, calling it in the lambda returns from the lambda. And since the proc is _also_ within the method context, calling it in the method returns from the method. The `call_proc` branching logic makes this look more complicated than it really is, but if you separate the logic I feel the behavior is rather reasonable. What do you think should be the behavior of `m2` below? ```ruby def m1 r = -> { proc = Proc.new{ return :return } proc.call #return from lambda :after_in_lambda }.call [:after_in_method, r] end def m2 r = -> { proc = Proc.new { return :return } }.call r.call #return from method :never_reached end p m1 #=> [:after_in_method, :return] p m2 #=> :return ``` ---------------------------------------- Bug #17105: A single `return` can return to two different places in a proc inside a lambda inside a method https://bugs.ruby-lang.org/issues/17105#change-86961 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- A single `return` in the source code might return to 2 different lexical places. That seems wrong to me, as AFAIK all other control flow language constructs always jump to a single place. ```ruby def m(call_proc) r = -> { # This single return in the source might exit the lambda or the method! proc = Proc.new { return :return } if call_proc proc.call :after_in_lambda else proc end }.call # returns here if call_proc if call_proc [:after_in_method, r] else r.call :never_reached end end p m(true) # => [:after_in_method, :return] p m(false) # :return ``` We're trying to figure out the semantics of `return` inside a proc in https://github.com/oracle/truffleruby/issues/1488#issuecomment-669185675 and this behavior doesn't seem to make much sense. @headius also seems to agree: > I would consider that behavior to be incorrect; once the proc has escaped from the lambda, its return target is no longer valid. It should not return to a different place. > https://github.com/jruby/jruby/issues/6350#issuecomment-669603740 So: * is this behavior intentional? or is it a bug? * what are actually the semantics of `return` inside a proc? The semantics seem incredibly complicated to a point developers have no idea where `return` actually goes. Also it must get even more complicated if one defines a `lambda` method as the block in `lambda { return }` is then non-deterministically a proc or lambda. -- https://bugs.ruby-lang.org/