Explicit return from a Ruby method - implementation hiding, reuse and optimisations.

Question

Hi,

Rather than allowing a Ruby method to blindly return the last statement evaluated, is there any advantage to returning nil explicitly?

In terms of implementation hiding and reuse, it seems dangerous to blindly allow the last expression evaluated to be returned - isn't there a danger that a user will rely on this only to get a nasty surprise when the implementation is modified? Surely returning nil would be better unless an explicit return value was given.

Following on, is there an optimisation that Ruby can make when the return is a simple type rather than a reference to a more complex object?

Chris

Answer 1

Unless you plan on doing something with the return value, I see no advantage.

I don't see a situation where someone would want to catch the return value of a function whose return value wasn't intended to be captured.

Someone correct me if I'm wrong, but the implicit return value has no practical use other than convenience.

---

Here's a hypothetical scenario where it might be useful

def func
  if do_something
    # we don't want to return the return value of do_something_else, so return nil
    do_something_else
    return nil
  end
  # we do want to return the return value of this function; however.
  do_foo
end

I find it highly unlikely it would occur

Answer 2

Generally speaking, no. I have never seen a function that, to avoid to return the value of the last executed statement, returns nil.
If the return value is used from the caller, then you can return nil to avoid that the result of the last statement is used from the caller. If the function is supposed to return a value, then I think that the code is wrongly written, if it doesn't explicitly return a value.

Answer 3

Looking at the second part of the question:

is there an optimisation that Ruby can make when the return is a simple type rather than a reference to a more complex object?

... I don't think it's worth worrying about. If there is a performance gain (and I rather doubt that there is) it's a micro-optimisation at best, and unlikely to deliver any benefit worth having. I suspect that trying both ways with require profile will show just how little can be gained. ;-)

Answer 4

Generally there are two types of methods, ie.

1. Functional methods - that returns a value after the method is run or called
2. Procedural methods - that changes the internal state of the object

An example of a functional method would be

def max(num, another_num)
  num > another_num ? num : another_num
end

which will return maximum number that can be used to perform some other computation.

A simple example of procedural method can be the setters or attribute accessors in ruby, like

class Person

  def name=(name)
    @name = name
  end

end

the above method is changing the internal state of the Person object i.e. by setting the instance variable @name to the value provided.

So it all depends what kind of method you are writing, the intention of your method and how you are going to use it. In other words, if its a procedural method then you can return nil at the end but personally I have never done that yet i.e. returning nil when only changing the state of the object because that will just add a line of code and also make the method look complex without adding any value to the method.

However, Ruby always returns the value of the last evaluated statement from the method whether it is a procedural or a functional method which actually makes it convenient to evaluate the method or some condition inside the method under some circumstances.

Answer 5

Yes, there are advantages to returning nil. I wouldn't worry them unless you're trying to provide an API though.