Bug #16340

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

Added by osyo (manga osyo) 26 days ago. Updated 24 days 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) 26 days 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) 24 days 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