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

• Status: Rejected
• 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

[osyo (manga osyo)]

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 {
  _1
  # return Numbered parameter(_1)
  eval("_1") # => :argument
}.call :argument

Actual behavior

_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

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

[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 _<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.

[osyo (manga osyo)]

@Eregon (Benoit Daloze)

Thanks comment!

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

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