What is this &:last Ruby construct called? [duplicate]

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!