Question

We define a function foo:

def foo(s)
  case s
  when'foo'
    x = 3
    puts x.inspect
  when 'bar'
    y = 4
    puts y.inspect
  end
  puts x.inspect
  puts y.inspect
end

We then call it as follows:

1.9.3p194 :017 > foo('foo')
in foo scope
3
in outer scope
3
nil
 => nil 

1.9.3p194 :018 > foo('bar')
in bar scope
3
in outer scope
nil
3
 => nil 

Why does the function not throw an error about an unregistered local variable in either case? In the first case, the variable y seems like it should not exist, so you can’t call inspect on it in the outer scope; the same for x in the second case.

Here’s another similar example:

def test1
  x = 5 if false
  puts x.inspect
end

def test2
  puts x.inspect
end

And then:

1.9.3p194 :028 > test1
nil
 => nil 

1.9.3p194 :029 > test2
NameError: undefined local variable or method `x' for main:Object

What’s going on here? It seems like Ruby is hoisting the variable declaration into the outer scope, but I wasn’t aware that this is something Ruby does. (Searching for “ruby hoisting” only turns up results about JavaScript hoisting.)

Answer 1

When the Ruby parser sees the sequence identifier, equal-sign, value,
as in this expression

x = 1

it allocates space for a local variable called x. The creation of the
variable—not the assignment of a value to it, but the internal
creation of a variable—always takes place as a result of this kind of
expression, even if the code isn’t executed! Consider this example:

if false
  x = 1
end
p x # Output: nil
p y # Fatal Error: y is unknown

The assignment to x isn’t executed, because it’s wrapped in a failing
conditional test. But the Ruby parser sees the sequence x = 1, from
which it deduces that the program involves a local variable x. The
parser doesn’t care whether x is ever assigned a value. Its job is
just to scour the code for local variables for which space needs to
be allocated. The result is that x inhabits a strange kind of variable limbo.
It has been brought into being and initialized to nil.
In that respect, it differs from a variable that has no existence at
all; as you can see in the example, examining x gives you the value
nil, whereas trying to inspect the non-existent variable y results
in a fatal error. But although x exists, it has not played any role in
the program. It exists only as an artifact of the parsing process.

Well-Grounded Rubyist chapter 6.1.2