From @masak

<moritz_> rakudo​: sub a() { 3, 4 }; my $x; my @​a = ($x = a(), 4); say @​a.perl
<p6eval> rakudo 4c31fb​: OUTPUT«[[3, 4, 4]]␤»
<moritz_> is that correct? or should it be [[3, 4], 4]?
<masak> moritz_​: well, things flatten, don't they?
<moritz_> masak​: there's also the question of relative precedence of , and =
<masak> moritz_​: I believe S03 is very clear on that.
<b2gills> rakudo​: sub a() { 3, 4 }; my $x; my @​a = (($x = a()), 4);
<p6eval> rakudo 4c31fb​: ( no output )
<b2gills> rakudo​: sub a() { 3, 4 }; my $x; my @​a = ($x = a(), 4); say $x.perl
<p6eval> rakudo 4c31fb​: OUTPUT«[3, 4, 4]␤»
<moritz_> masak​: if naively read the precedence table in S03 then it
tells me that = is tighter, and therefore $x should only get the
elements from a()
<masak> moritz_​: no, there's a whole section on list assignment.
<masak> line 1785.
<masak> and it carries on explaining until S03​:1861.
<pmichaud> if the left hand side of eq is a scalar, it's an item
assignment, and = binds tighter than comma
<pmichaud> at present Rakudo doesn't do that -- it treats all ='s as
list assignment
<pmichaud> sorry, it parses all ='s as list assignment
<pmichaud> so Rakudo will incorrectly see $x = a(), 4 as being $x
= (a(), 4) instead of ($x = a()), 4
<moritz_> pmichaud​: ok, that answers my question
<moritz_> and that's indepent of a possible @​a = to the left of the
whole expression, right?
<pmichaud> correct.
<moritz_> thank you.
<masak> so... it's a bug? :>
<moritz_> aye.
* masak submits

From @moritz

plenty of tests can be found in t/spec/S03-operators/assign.t.

The RT System itself - Status changed from 'new' to 'open'

From @jnthn

On Mon Jul 27 13​:03​:23 2009, moritz wrote​:

plenty of tests can be found in t/spec/S03-operators/assign.t.

Item assignment is now implemented, so I suspect we can unfudge some of
those. :-) Giving to moritz++.

/jnthn

@moritz - Status changed from 'open' to 'resolved'