my @keys;
  @new{ @keys } = @orig{ @keys = grep /[adf]/, keys %orig };
[download]

  my @keys = grep /[adf]/, keys %orig;
  @new{ @keys } = @orig{ @keys };
[download]

I was surprised that this not only works, but also does not complain if strictures are added to the code.

The code looks ingenious, but I wonder about two aspects: First, you are accessing a list one time as a hash via %NAME, and then the same list as an array, via @NAME. Is this considered accepted practice? Honestly, I hadn't expected it to work with lexically scoped variables, and I'm not sure whether this trick (if I can call it like this) will remain with later Perl versions.

@new{ @keys } = @orig{ @keys = grep /[adf]/, keys %orig };
[download]

All of the references are to the hashes %new and %old; the leading @ and curlies is just the way you name slices. The only array involved in the whole thing is @keys.

As for relying on the ordering, I think it's pretty safe to count that the rvalue will be computed and available before the lvalue is populated with it.

The cake is a lie.
The cake is a lie.
The cake is a lie.

I think it's pretty safe to count that the rvalue will be computed and available before the lvalue is populated with it.

In general, no. The container can be placed on the stack before the value it will receive. The assignment only occurs after both the value and the container are on the stack.

In Perl, operands are always evaluated from left to right, except the operands for assignment operators are always evaluated from right to left. But that's not documented.

	Given	Disinguishes these Interpretations
Operator Precedence	1+2*3	(1+2)*3 -vs- 1+(2*3)
Operator Associativity	2**3**4	(2**3)**4 -vs- 2**(3**4)
Operand Evaluation Order	foo()+bar()	foo() -> bar() -> add -vs- bar() -> foo() -> add

Update: I foresaw confusion between operator associativity and operand evaluation order, so I added the table.