Bug #20308
closed`it` and numbered parameters do not work in `eval`
Description
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?
Updated by matheusrich (Matheus Richard) 8 months ago
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
Updated by jeremyevans0 (Jeremy Evans) 8 months ago
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.
Updated by alanwu (Alan Wu) 8 months ago ยท Edited
Looks like it's a known limitation and discussed before in #18837.
Updated by kddnewton (Kevin Newton) 8 months ago
Ahh! Thank you @jeremyevans0 (Jeremy Evans) and @alanwu (Alan Wu) I knew there must have been a reason. I'll close this.
Updated by kddnewton (Kevin Newton) 8 months ago
- Status changed from Open to Closed
Updated by nobu (Nobuyoshi Nakada) 8 months ago
- Is duplicate of Bug #18837: Not possible to evaluate expression with numbered parameters in it added