Project

General

Profile

Bug #11074

Block with optional parameter of same closure variable name

Added by charlton (Charlton Wang) almost 4 years ago. Updated almost 4 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Target version:
-
ruby -v:
ruby 2.1.1p76 (2014-02-24 revision 45161) [x86_64-linux]
[ruby-core:<unknown>]

Description

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


Related issues

Related to Ruby trunk - Bug #9593: Keyword arguments default argument assignment behaviour not consistent with optional argumentClosed03/05/2014Actions

History

#1

Updated by nobu (Nobuyoshi Nakada) almost 4 years ago

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

Updated by nobu (Nobuyoshi Nakada) almost 4 years ago

  • 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.

Also available in: Atom PDF