What is this &:last Ruby Construct Called?

Question

What are things like survey.map(&:questions).flatten.compact called, so I can find more information about them :). What problems does that &: solve, or what is it doing exactly? Is it used in other languages?

Answer 1

This is shorthand for:

survey.map { |s| s.questions }.flatten.compact

It's the Symbol#to_proc method. It used to be a part of Rails' ActiveSupport, but has since been added to Ruby syntax.

As far as performance goes, I wrote a quick benchmark script to get an idea of performance effect in both 1.8 and 1.9.

require 'benchmark'

many = 500
a = (1..10000).to_a

Benchmark.bm do |x|
  x.report('block once') { a.map { |n| n.to_s } }
  x.report('to_proc once') { a.map(&:to_s) }
  x.report('block many') { many.times { a.map { |n| n.to_s } } }
  x.report('to_proc many') { many.times { a.map(&:to_s) } }
end

First off, before giving you the results - if you weren't already sure that Ruby 1.9 was a huge speed improvement in general, prepare to be blown away.

Ruby 1.8 results:

     user     system      total        real
block once  0.020000   0.000000   0.020000 (  0.016781)
to_proc once  0.010000   0.000000   0.010000 (  0.013881)
block many  6.680000   1.100000   7.780000 (  7.780532)
to_proc many  7.370000   0.540000   7.910000 (  7.902935)

Ruby 1.9 results:

      user     system      total        real
block once  0.010000   0.000000   0.010000 (  0.011433)
to_proc once  0.000000   0.000000   0.000000 (  0.004929)
block many  4.060000   0.000000   4.060000 (  4.057013)
to_proc many  2.810000   0.000000   2.810000 (  2.810312)

First off: Wow. Ruby 1.9 is fast. But the more relevant conclusions we draw here are interesting:

• In both cases, for only one run, to_proc is clearly faster. In 1.8 on the many-times run, it's tad slower. This seems to indicate that the only real performance bottleneck is creating all those Proc objects.
• In Ruby 1.9, however, the to_proc method is clearly much faster than blocks, no matter how many times you do it. In this case, you not only get cleaner code, but improved performance, as well.

In the end, no matter which version you're using, to_proc is clearly not enough of a performance issue to be worth not using - in fact, it sometimes speeds things up!