I agree that there should be some syntax for doing this, but I don't think this is the proper way to do it.

Personally, the syntax is confusing to me. I would prefer something like:

[1,2,16].map(&:to_s(16))

This way, the way my brain parses it is that &: is the operator for turning a symbol into a block that calls the method on the argument. However, this would require changes in the parser instead of stdlib.

My other concern is that Symbol#call returning a proc feels wrong. It leads to code like this:

a=:to_sa.call(16).call(15)

While such code may never be written even if this is implemented, I hope it conveys how odd it feels to have a method named "call" always return a proc which is then meant to be called, instead of calling anything.

Would the change from &(:meth_name_as_symbol) to special operator &: followed by method name and optionally arguments (ie. the syntax I used above) break any existing code?

I disagree: responding to to_proc in Ruby more or less means "I am a function-like thing". And arrays are function-like things, they are basically functions from their indices to their values. Having to_proc mean something different than that would be a big mistake, IMO. It would also be inconsistent with Hash#to_proc.

See #11653 (Hash#to_proc) for what I mean, and #11262 for a more comprehensive argument.

I disagree: responding to to_proc in Ruby more or less means "I am a function-like thing". And arrays are function-like things, they are basically functions from their indices to their values. Having to_proc mean something different than that would be a big mistake, IMO. It would also be inconsistent with Hash#to_proc.

Even if arrays were function-like things, the elements are not arguments.

I disagree: responding to to_proc in Ruby more or less means "I am a function-like thing". And arrays are function-like things, they are basically functions from their indices to their values. Having to_proc mean something different than that would be a big mistake, IMO. It would also be inconsistent with Hash#to_proc.

Even if arrays were function-like things, the elements are not arguments.

In Jörg's proposals, array elements are indeed not arguments, they are return values. Index values are arguments.

I think &[symbol, *args] can be a natural extension to &symbol, as they are both a shorthand for { |_| _.__send__(*object) }.

For Array to provide #to_proc would be just a little bit weird convention for greater convenience, just as Symbol#to_proc is. Symbol had been in no way a function-like entity, but once Symbol#to_proc was added we almost instantly grew used to it and now we all take it for granted because being able to map(&:to_s) is so handy and useful.

The original proposal that is to introduce a new syntax is a bit too costly for one of the most frequently wanted features like this because it takes years of time before everyone can start using it. On the other hand, adding Array#to_proc is easily backportable and you can start using it today. FWIW, Matz once said he was not in favor of extending the syntax just for this: http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-dev/45404?45384-45592 (written in Japanese, try Google translate)

I've done some more googling and it turned out that Array#to_proc was not a new idea at all.