As a single contributor that's trying to hack together an idea, the second option is not so bad; however, it will probably need to be changed far off in the future.
I think named block parameters are cool in the sense that they enable some expressiveness but bad in the sense that they lose some readability. I won't know how I truly feel until I have to maintain/read a large codebase where they are used.
[1,2,3].map{|n| n * 2}
to:
[1,2,3].map{it * 2}
?
It's not generalizable to multi-argument lambdas, but multi-argument lambdas are the ones that are more important to name. (e.g. with reduce, {|memo, it| memo += it})
I think as far as Ruby goes, I don't like the idea of introducing a new abstraction for something that already has a solution; however, I wouldn't villify someone for using it unless they wrote something that took a large number of arguments.
[1,2,3].map{_*2}
I think that's what Scala has. For multi-args, perhaps: [1,2,3].reduce{_1+=_2} begin anonymous function
arguments are dividend and divisor
return dividend over divisor
end
There; no cryptic one-character anything. No curly braces, no commas, no operators.