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=-2.9 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,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 6532F1F990 for ; Thu, 6 Aug 2020 23:47:34 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 9D05F120B6B; Fri, 7 Aug 2020 08:47:00 +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 F20D6120B68 for ; Fri, 7 Aug 2020 08:46:57 +0900 (JST) Received: by filterdrecv-p3iad2-d8cc6d457-bt7pn with SMTP id filterdrecv-p3iad2-d8cc6d457-bt7pn-18-5F2C9687-2A 2020-08-06 23:47:19.446120221 +0000 UTC m=+711537.192116541 Received: from herokuapp.com (unknown) by ismtpd0037p1iad2.sendgrid.net (SG) with ESMTP id uHStfjgHTmGWNnhDykZDyw for ; Thu, 06 Aug 2020 23:47:19.390 +0000 (UTC) Date: Thu, 06 Aug 2020 23:47:19 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 75331 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 17105 X-Redmine-Issue-Author: Eregon 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?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr3uOB6EfskJSc4rjhbGh7?= =?us-ascii?Q?kGZY3Db6is2+dYNBQYs1Sh=2Fb8ht08=2FI0bMIR3kf?= =?us-ascii?Q?1C7F=2FVOiypVxBuuMchl07dDo9U3oq=2FtS4Lf28pf?= =?us-ascii?Q?36tsr+z84kaxYNzxV2B1823ZGLyZPLZJWbf4q5d?= =?us-ascii?Q?aOXvqU23mpbj5nuGAANCTiPUrECCaa6MFlE2dpT?= =?us-ascii?Q?f5oD=2FzMWk1RZHK1rA=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 99505 Subject: [ruby-core:99505] [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 Eregon (Benoit Daloze). IMHO it should be a LocalJumpError. The Proc should return to the lambda, that's syntactically the closest scope it should return to. Since it's not possible to return it (the lambda is no longer on stack), it should be a LocalJumpError. ---------------------------------------- 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-86962 * 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/