So don't make your copy first. It's a reference after all, which in this case makes life easy.
my @copy;
while (@$r) {
push @copy, [ shift @$r, shift @$r ];
}
$r = \@copy;
This way we build our new array (while the one gets bigger, the other gets smaller), then we simply change what the reference points to. | [reply] [Watch: Dir/Any] [d/l] |
That's very neat.   My only point was that the way grinder was presenting it (non-destructive of the original array), it would probably not be the fastest if the array copy was not hidden in the overhead for the subroutine call.
  p
| [reply] [Watch: Dir/Any] |
I'm sorry. I guess I thought his requirements didn't preclude a destructive routine, since he opens with $r = [1,2,3,4,5,6] and wants to replace that with $r = [[1,2],[3,4],[5,6]] and both the shifter and splicer techniques in the benchmark are destructive. My money's on the c-loop for non-destructive, and if I had large tuples or frequently changing tuple lengths, I'd use splicer in spite of the speed hit shown here.
| [reply] [Watch: Dir/Any] [d/l] [select] |