Bug #16340


There are cases where `eval("_ 1")` does not refer to Numbered parameter

Added by osyo (manga osyo) almost 2 years ago. Updated almost 2 years ago.

Target version:
ruby -v:
ruby 2.7.0dev (2019-11-11T10:03:43Z trunk 9d3213ac85) [x86_64-linux]


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

_1 = :local_variable
proc {
  # return Numbered parameter(_1)
  eval("_1") # => :argument
}.call :argument

Actual behavior

_1 = :local_variable
proc {
  # 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.


  • Return Numbered parameter if not define local variables outside block
# _1 = :local_variable
proc {
  # Actual behavior
  # return Numbered parameter
  eval("_1") # => :argument
}.call :argument

Updated by Eregon (Benoit Daloze) almost 2 years ago

  • 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 _<n> 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.

Updated by osyo (manga osyo) almost 2 years ago

Eregon (Benoit Daloze)

Thanks comment!

Do you have any realistic use case where you would want your expected behavior?

However, I thought it was strange behavior and reported.
I agree to reject.


Also available in: Atom PDF