Bug #20308: `it` and numbered parameters do not work in `eval`

• Status: Closed
• Assignee: -
• Target version: -
• Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN

[kddnewton (Kevin Newton)]

I am not sure if this is a purposeful restriction or not, so I apologize if this is not a "bug" per se.

Currently if you use it or _1 (numbered parameters) in eval they do not work with compile.c:

irb(main):001> 1.tap { eval("_1") }
(eval):1:in `block in <top (required)>': undefined local variable or method `_1' for main:Object (NameError)
Did you mean?  _

They work accidentally with prism because I didn't know this wasn't allowed. Is it a bug? Or is this on purpose?

[matheusrich (Matheus Richard)]

Interesting behavior. I'd expect that to work since other "kinds of arguments" work:

def foo(*)
  eval "puts(*)"
end

def foo(**)
  eval "puts(**)"
end

def foo(...)
  eval "puts(...)"
end

[jeremyevans0 (Jeremy Evans)]

My understanding is the parse.y behavior is expected, because use of _1/it inside the block changes the block's arity:

lambda{it}.arity
# => 1
lambda{eval('it')}.arity
# => 0

So if we supported eval('it') in non-lambda procs, it would make support inconsistent with lambda procs.

[alanwu (Alan Wu)]

Looks like it's a known limitation and discussed before in #18837.

[kddnewton (Kevin Newton)]

Ahh! Thank you @jeremyevans0 (Jeremy Evans) and @alanwu (Alan Wu) I knew there must have been a reason. I'll close this.

[kddnewton (Kevin Newton)]

• Status changed from Open to Closed

[nobu (Nobuyoshi Nakada)]

• Is duplicate of Bug #18837: Not possible to evaluate expression with numbered parameters in it added