Why does explicit return make a difference in a Proc?

RubyReturnProc Object

Ruby Problem Overview

def foo
  f = Proc.new { return "return from foo from inside proc" }
  f.call # control leaves foo here
  return "return from foo" 

def bar
  b = Proc.new { "return from bar from inside proc" }
  b.call # control leaves bar here
  return "return from bar" 

puts foo # prints "return from foo from inside proc" 
puts bar # prints "return from bar" 

I thought the return keyword was optional in Ruby and that you are always returning whether you request it or not. Given that, I find it surprising that foo and bar have different output determined by the fact that foo contains an explicit return in Proc f.

Does anyone know why this is the case?

Ruby Solutions

Solution 1 - Ruby

Ruby has three constructs:

  1. A block is not an object and is created by { ... } or do ... end.
  2. A proc is a Proc object created by Proc.new or proc.
  3. A lambda is a Proc created by lambda (or proc in Ruby 1.8).

Ruby has three keywords that return from something:

  1. return terminates the method or lambda it is in.
  2. next terminates the block, proc, or lambda it is in.
  3. break terminates the method that yielded to the block or invoked the proc or lambda it is in.

In lambdas, return behaves like next, for whatever reason. next and break are named the way they are because they are most commonly used with methods like each, where terminating the block will cause the iteration to resume with the next element of the collection, and terminating each will cause you to break out of the loop.

If you use return inside the definition of foo, you will return from foo, even if it is inside a block or a proc. To return from a block, you can use the next keyword instead.

def foo
  f = Proc.new { next "return from foo from inside proc" }
  f.call # control leaves foo here
  return "return from foo" 
puts foo # prints "return from foo"

Solution 2 - Ruby

This is the semantics for Procs; it is not necessarily the semantics for all blocks. I agree this is a bit confusing. It is there for added flexibility (and perhaps partially cause Ruby has no spec except for its implementation).

The behavior is defined in the Proc implementation. Lambdas behave differently, so if you would like your returns not to exit out of the enclosing method, use lambdas. Or, omit the return keyword from your Proc.

A deep investigation of Rubys closures is here. It is a fantastic exposé.


def foo   
  f = Proc.new {
    p2 = Proc.new { return "inner proc"};
    return "proc"
  return "foo"

def foo2
  result = Proc.new{"proc"}.call
  "foo2 (proc result is: #{result})"

def bar
  l = lambda { return "lambda" }
  result = l.call
  return "bar (lambda result is: #{result})"

puts foo
# inner proc
puts foo2
# foo (proc result is: proc) 
puts bar
# bar (lambda result is: lambda) 

Solution 3 - Ruby

Think of it this way: Proc.new just create a block of code that is part of the calling function. proc/lambda create an anonymous function that has special bindings. A little code examples will help:

def foo
  f = Proc.new { return "return from foo from inside Proc.new" }
  f.call # control leaves foo here
  return "return from foo" 

is equivalent to

def foo
    return "return from foo from inside begin/end" }
  return "return from foo" 

so it is clear that the return will just return from the function 'foo'

in contrast:

def foo
  f = proc { return "return from foo from inside proc" }
  f.call # control stasy in foo here
  return "return from foo" 

is equivalent to (ignoring the bindings since not used in this example):

def unonymous_proc
  return "return from foo from inside proc"

def foo
  return "return from foo" 

Which is as clearly will not return from foo and continue to the next statement instead.


All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionuzoView Question on Stackoverflow
Solution 1 - Rubysepp2kView Answer on Stackoverflow
Solution 2 - RubySam SaffronView Answer on Stackoverflow
Solution 3 - RubyVitaly KushnerView Answer on Stackoverflow