@mortonfox, As I said it's a good solution. I think the comments section is a good place to discuss tradeoffs that may not be obvious to evey user, such as performance issues. That way someone seeing these for the first time can make the best informed decision in the future.

Test cases are broken; as others have pointed out. Would be nice if there was a feature where the community could directly edit the test cases to fix and self moderate. This is an easy fix that would have been taken care of months ago if we had the ability to do some self moderation.

This kata appears to pass no matter what code is used to define the method...

Clever is the tag chosen by Codewars; this wasn't some kind of slight. It's a good solution, but performance is sub-optimal and the better performing solution is also easier to read.

And to say "As for performance, don't use Ruby", that's just silly. It doesn't matter what language someone is developing in performance should be a consideration. This isn't a case of pre-mature optimization. It's an easy performance gain. I provided the benchmark for anyone that might come along in the future to be helpful as they may not be aware of the performance difference.

So obvious once I saw it; but didn't cross my mind when I was trying to solve it. Nice one!

This is certainly a clever solution and deserving up the the up votes for that. I'm surprised that this is so heavily upvoted though for "Best Practices", in comparison to the more direct map enumeration version here http://www.codewars.com/kata/reviews/5356b77a2930ee4c010007e6/groups/5397a4c4c20318c06e000ea0

While this technique is certainly clever, I don't believe it is as readable to the average developer and the performance is worse.

The results posted below are from benchmarking this solution against the standard map enumerable. This to_proc version shown here is about 8% slower. So you lose speed and code legibility.

Calculating -------------------------------------
            proc    47.361k i/100ms
             std    52.963k i/100ms
-------------------------------------------------
            proc    980.817k (± 7.3%) i/s -      4.878M
             std      1.060M (± 7.3%) i/s -      5.296M