Ruby » Ruby master

It does seem like that last one should be [:it] for consistency if it wasn't intentional. +1

An aside, but it's also interesting that using _2 causes _1 to also be defined under Binding#local_variables.

proc { _9; local_variables }.call
# => [:_1, :_2, :_3, :_4, :_5, :_6, :_7, :_8, :_9]

proc { it; local_variables }.call
# => []

https://github.com/ruby/ruby/pull/12398

I have a concern of making it parameter an lvar.

1| 42.tap do
2|   p binding.local_variable_get('it')
3|   it /1/i
4|   p it
5| end

When parser reads p it at line 4, it turns out to be a local variable, I think from the beginning of the block(from line 2).
But on line 3, it /1/i is already parsed as if lvar it does not exist.

It is impossible to re-parse the block again, so the original implementation(it parameter is not an lvar) makes sense to me.

Interestingly, numbered block parameters do this:

"foo".tap do
  _1
  "bar".tap do
    p binding.local_variables #=> [_1]
    eval("_1") #  undefined local variable or method '_1' for main:Object (NameError)
  end
end

I am not saying this is good behavior, though. The things I am concerned about (after the release, of course):

1. Whatever the behavior is, it is deliberate and documented;
2. Whatever the behavior is, it is internally consistent (e.g., in #20955 the thing that surprised me was an inconsistency between proc and lambda);
3. Whatever the behavior is, I’d expect it to be as consistent as possible between it and numbered anonymous parameters.

(About the latter one: its behavior, after the change is reverted, actually seems more internally consistent at least between local_variables and eval, so maybe numbered parameters should follow?)

I see. I think this is simply buggy.

"foo".tap do
  _1
  "bar".tap do
    p binding.local_variable_get(:_1) #=> "foo"
  end
end

IMO, meta-programming APIs for numbered parameters and it should be separated from binding#local_variable* because they are not a local variable. It would be good to consider them towards 3.5.