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 A8D501F454 for ; Mon, 11 Nov 2019 13:40:38 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id CA8A9120A01; Mon, 11 Nov 2019 22:40:22 +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 1321412099E for ; Mon, 11 Nov 2019 22:40:19 +0900 (JST) Received: by filter0076p3iad2.sendgrid.net with SMTP id filter0076p3iad2-25672-5DC964C3-3D 2019-11-11 13:40:19.391015117 +0000 UTC m=+315198.758876018 Received: from herokuapp.com (unknown [35.171.185.2]) by ismtpd0093p1iad2.sendgrid.net (SG) with ESMTP id ZNNTWNbUR9qWGJWLp1Ua6g for ; Mon, 11 Nov 2019 13:40:19.359 +0000 (UTC) Date: Mon, 11 Nov 2019 13:40:19 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 71412 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16340 X-Redmine-Issue-Author: osyo 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?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr0gaYeTYfhXbMiXCV+zfO?= =?us-ascii?Q?paATr=2FD5IgFVwh6wT6fUiYbA+RBJ+r9ZIpkzvJh?= =?us-ascii?Q?PYeKnUNqj2TohDWHgO9+iPJdC++SHat+rgODuv1?= =?us-ascii?Q?IbLYb+erhBricmm4JnDydtst30QqyElee16xVeY?= =?us-ascii?Q?WeapNe21t+XHDfUmSP0opI9nHgMUxU8XomA=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95787 Subject: [ruby-core:95787] [Ruby master Bug#16340] There are cases where `eval("_ 1")` does not refer to Numbered parameter 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 #16340 has been updated by Eregon (Benoit Daloze). Status changed from Open to Rejected I think the behavior is expected. `_1` is a local variable in your example and eval can access local variables outside of it. However, I don't think `_1` can work as numbered parameter inside an eval for a block outside the eval, because then we'd change the block arity dynamically. What would be the Proc#arity of `lambda { _1 + eval("_#{rand(5)}") }.arity` ? IMHO, `_1` shouldn't be supported inside `eval` as a numbered parameter when it refers to something outside `eval`. So I think the current behavior is fine, and needs to be kept for compatibility if `_` is used as a local variable. Do you have any realistic use case where you would want your expected behavior? I mark this as rejected because I believe it's unsolvable. ---------------------------------------- Bug #16340: There are cases where `eval("_ 1")` does not refer to Numbered parameter https://bugs.ruby-lang.org/issues/16340#change-82608 * Author: osyo (manga osyo) * Status: Rejected * Priority: Normal * Assignee: * Target version: * ruby -v: ruby 2.7.0dev (2019-11-11T10:03:43Z trunk 9d3213ac85) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- ## Steps to reproduce 1. Define local variable `_1` outside block 2. Call Numbered parameter in block 3. Call `eval("_1")` in same block ## Expected behavior ```ruby _1 = :local_variable proc { _1 # return Numbered parameter(_1) eval("_1") # => :argument }.call :argument ``` ## Actual behavior ```ruby _1 = :local_variable proc { _1 # return local variables outside block eval("_1") # => :local_variable }.call :argument ``` This is strange behavior because I want to expect to reference `_1` in block. ## Note * Return Numbered parameter if not define local variables outside block ```ruby # _1 = :local_variable proc { _1 # Actual behavior # return Numbered parameter eval("_1") # => :argument }.call :argument ``` -- https://bugs.ruby-lang.org/