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
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
or to avoid it returning
a 1 b *random* c 3 d 4 b 5
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
|