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=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, 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 71BB21F8C6 for ; Mon, 9 Aug 2021 19:00:12 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 2D315120AA8; Tue, 10 Aug 2021 03:58:51 +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 E4BA2120A8C for ; Tue, 10 Aug 2021 03:58:48 +0900 (JST) Received: by filterdrecv-765fd4f9f8-2fns7 with SMTP id filterdrecv-765fd4f9f8-2fns7-1-61117B34-5A 2021-08-09 19:00:04.308391904 +0000 UTC m=+445249.097128636 Received: from herokuapp.com (unknown) by ismtpd0202p1mdw1.sendgrid.net (SG) with ESMTP id _iKno7U1RpCMUhSIcAw9sw for ; Mon, 09 Aug 2021 19:00:04.183 +0000 (UTC) Date: Mon, 09 Aug 2021 19:00:04 +0000 (UTC) From: merch-redmine@jeremyevans.net Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 18069 X-Redmine-Issue-Author: ttanimichi X-Redmine-Sender: jeremyevans0 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-Redmine-MailingListIntegration-Message-Ids: 80987 X-SG-EID: =?us-ascii?Q?RVE3t853K5scBhbmJHUzZTFFeVC=2FZSUmHZ0Dc+26wcEi2CTgsF1oz0wTSSxGGN?= =?us-ascii?Q?BIsAsBEumfxKb61V=2FQE3prc1Uug0AZD5bSsdY8A?= =?us-ascii?Q?OVIV2FOrtPXIsVsE8LtZYdQXbBv0H2zFyL=2Fe2xp?= =?us-ascii?Q?YCGuBquCwqMlxbmXgsL2ReQ=2F3Gfcedv1kLNxJGG?= =?us-ascii?Q?SRkh4egambvDjPmIla7Nv95gr6wC89gLLvUYhBm?= =?us-ascii?Q?fbvGFDq6QsS8gbN98=3D?= To: ruby-dev@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-dev X-Mail-Count: 51091 Subject: [ruby-dev:51091] [Ruby master Feature#18069] `instance_exec` is just ignored when the block is originally a method X-BeenThere: ruby-dev@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Ruby developers \(Japanese\)" List-Id: "Ruby developers \(Japanese\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ruby-dev-bounces@ruby-lang.org Sender: "ruby-dev" Issue #18069 has been updated by jeremyevans0 (Jeremy Evans). Backport deleted (2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN) Tracker changed from Bug to Feature I don't think the current behavior is a bug. `Method#to_proc` is currently equivalent to: ```ruby class Method def to_proc method = self ->(*args, **kwargs, &block) do method.call(*args, **kwargs, &block) end end end ``` You wouldn't expect an `instance_exec` on that lambda to change the behavior of `Method#call`. So I think the current behavior is expected. Note that it's not hard to change the behavior to raise an error in this case (and other cases like `module_exec`). However, changing the behavior would result in significant backwards compatibility issues. I tried a commit that raises ArgumentError in such a case: https://github.com/jeremyevans/ruby/commit/3e2db2f01281f2335c638142223f8b24531826bd. However, it broke quite a few tests: https://github.com/jeremyevans/ruby/runs/3283493124. Some of the breakage may be due to implementation choice, but I checked and at least some of the breakage is unavoidable as the tests expect to pass procs created by `Method#to_proc` to `instance_exec` (e.g. `test_instance_exec_define_method_kwsplat`). As I don't think this is a bug, I'm switching this to a feature request. ---------------------------------------- Feature #18069: `instance_exec` is just ignored when the block is originally a method https://bugs.ruby-lang.org/issues/18069#change-93200 * Author: ttanimichi (Tsukuru Tanimichi) * Status: Open * Priority: Normal ---------------------------------------- I know you can't `instance_exec` a proc which is generated by `Method#to_proc` because it has its original instance's context. But, in such a case, raising `ArgumentError` would be the ideal behavior. ```ruby f = -> (x) { a + x } class A def a 1 end end A.new.instance_exec(1, &f) # => 2 class B def b(x) a + x end end proc = B.new.method(:b).to_proc A.new.instance_exec(1, &proc) # => undefined local variable or method `a' for # (NameError) ``` -- https://bugs.ruby-lang.org/