Bug #11074: Block with optional parameter of same closure variable name

• Status: Rejected
• Assignee: -
• Target version: -
• ruby -v: ruby 2.1.1p76 (2014-02-24 revision 45161) [x86_64-linux]
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN

[charlton (Charlton Wang)]

def bar
   yield
end
x = 3
bar do |x=x|
  x
end
=> nil
bar do |y=x|
  x
end
=> 3

So perhaps x=x isn't able to distinguish that the RHS should probably be the closure x and, instead, is take to mean the value of the (new and uninitialized) x parameter of the block. But then:

def foo(x=x)
   x
end
foo(3)
=> 3
foo
=> NameError: undefined local variable or method `x' for main:Object

So at least in this case, it knows that x on the RHS isn't the parameter variable x. This seems a bit inconsistent.

One can get some really odd results as well:

def foo(x)
   bar do |x=x|
      x
   end
end
foo(1)
=> 491
foo(1)
=> 498
foo(1)
=> 505

In this case, x=x doesn't render nil as in the previous case. The value of x being returned always increases by 7. Is doing something like x=x as a parameter (to a block) generally viewed as being "undefined" behaviour?

Thanks,
Charlton

[nobu (Nobuyoshi Nakada)]

• Related to Bug #9593: Keyword arguments default argument assignment behaviour not consistent with optional argument added

[nobu (Nobuyoshi Nakada)]

• Description updated (diff)
• Status changed from Open to Rejected

Charlton Wang wrote:

def foo(x=x)
   x
end
foo(3)
=> 3
foo
=> NameError: undefined local variable or method `x' for main:Object

So at least in this case, it knows that x on the RHS isn't the parameter variable x. This seems a bit inconsistent.

It's an already fixed bug.