G'day LanX,

I can't reproduce this with v5.18.1 (darwin-thread-multi-2level):

$ perl -MData::Dumper -e ' %h1=(3 => 1, 5 => 1, 10 => 3 ); @l=%h2=reve
+rse %h1; print Dumper \@l,\%h2'
$VAR1 = [
          1,
          '3',
          3,
          '10'
        ];
$VAR2 = {
          '1' => '3',
          '3' => '10'
        };
$ perl -MData::Dumper -e ' %h1=(3 => 1, 5 => 1, 10 => 3 ); %h4=%h3=%h2
+=reverse %h1; print Dumper \%h2,\%h3,\%h4'
$VAR1 = {
          '1' => '3',
          '3' => '10'
        };
$VAR2 = {
          '1' => '3',
          '3' => '10'
        };
$VAR3 = {
          '1' => '3',
          '3' => '10'
        };
[download]

In v5.18.0, there were changes to hashes (see perl5180delta: Hash overhaul). This meant that running these one-liners (potentially) produced different results each time. I ran these a few times: I got different results as expected but none reproduced what you're seeing. Here's some examples of this:

my @count = qw/ 3 1 5 1 10 3 /;
my @list= my %rcount = reverse @count;
say "@list"
__END__
1 1 1 1
[download]

ok since 5.14.1, broken in 5.12.2

https://rt.perl.org/rt3/Public/Search/Simple.html?q=reverse -> #31865: weird results from reverse( %x = reverse %h ) , whats wrong reverse %x = reverse %h?

Looks like the same bug and at Sep 11 15:56:56 2010 davem - Fixed In 5.13.5 added

I like these variations:

say "@a = %h = ( a=>1, b=>2, c=>3, d=>4, a=>5 )"
b 2 b 2 c 3 d 4
say "@a = %h = ( a=>1, b=>2, c=>3, d=>4, b=>5 )"
b b b b c 3 d 4
say "@a = %h = ( a=>1, b=>2, c=>3, d=>4, c=>5 )"
b 2 b 2 c b d 4
say "@a = %h = ( a=>1, b=>2, c=>3, d=>4, d=>5 )"
b 2 b 2 c 3 d b
[download]

As for explanation, I find it an unimportant quirk. I've never seen the desired behavior defined. I could guess at a few behaviors that I might expect. I'd hate for something to be made less efficient for the sake of making this particular construct return something less surprising.

I'd be fine with only the case of @a = %h = ... being made less efficient by translating it into: @a = do { %h = ...; %h }.

There have been several times where I have used %h = @a = ..., and the behavior of that is well defined. That line is usually followed by code to pull out just the keys from @a because I care about the order in which the keys were given.

The current return values hint that an attempt might have been made to make this return what %h would return except preserving the original order of the items as much as possible. That would be an interesting result that might even be useful. If that can be achieved by relatively simple work that doesn't adversely impact efficiency or code complexity, then I'd be in favor of that.

My admittedly wild guess is that the return values might actually be the result of trying to get the construct to return:

this: a 1 c 3 d 4 b 5
 not: a 1 b 5 c 3 d 4
[download]

or to avoid it returning

a 1 b *random* c 3 d 4 b 5
[download]

and perhaps even *random* potentially resulting in core dumps. :)

But my favorite result would be for it return:

this: a b c d
  or: a c d b
  or: a b c d b
[download]

The usability of

@l=%h2=reverse %h1;

may be debatable ...

But %h2 identical to %h3 in

%h3=%h2=reverse %h1;

is IMHO normal expected behavior.

The problem is related to collisions, no collisions no problems.

lanx@nc10-ubuntu:~$ perl -MData::Dumper -e ' @h1=(1 => 3, 2 => 5, 3 =>
+ 10); %h3=%h2=@h1; print Dumper \%h2,\%h3'
$VAR1 = {
          '1' => 3,
          '3' => 10,
          '2' => 5
        };
$VAR2 = {
          '1' => 3,
          '3' => 10,
          '2' => 5
        };
[download]

Cheers Rolf

( addicted to the Perl Programming Language)

I'm getting old! o_O

return of hash-assigment in list context (bug?) (by LanX)

PS: I'm getting old.

PS: I'm repeating myself.

...

PS: I'm getting old.