Feature #18069
open`instance_exec` is just ignored when the block is originally a method
Description
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.
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 #<B:0x00007fdaf30480a0> (NameError)
Updated by jeremyevans0 (Jeremy Evans) over 3 years ago
- Tracker changed from Bug to Feature
- Backport deleted (
2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN)
I don't think the current behavior is a bug. Method#to_proc
is currently equivalent to:
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.
Updated by nobu (Nobuyoshi Nakada) over 3 years ago
A method is bound to the internal states of the receiver.
I don't think that removing the receiver from a method makes sense.