I'm in the mood to question my sanity, so I'm seeking feedback for some
test mangling:
In t/spec/S03-operators/assign.t there are some tests that cause me a
headache. I'm trying to re-write them to not use the now-gone want()
function, but I'd have to understand them first ;-)
A good example is this one:
sub W () { substr(eval('want'), 0, 1) }
...
# line 560:
{
my @a;
my @z = (@a[0] = W, W);
#?rakudo 2 todo 'want function'
is(@a, 'L', 'lhs treats @a[0] as list');
is(@z[0], 'L', 'lhs treats @a[0] as list');
ok(!defined(@z[1]), 'lhs treats @a[0] as list');
}
This tests that
1) both calls to want() are in list context
2) @a[0] gets only the return value of the first call to W()
3) @z[0] gets the same thing
4) There's no item for @z[1]
Somehow I think this test (and many similar tests) are dead wrong.
Here's why:
Either it's parsed as '@a[0] = (W, W)' (list assignment), then @a should
get both elements, and so should @z.
Or it's parsed as '(@a[0] = W), W' (item assignment), then the first
call should be in item context, and the second one in list context, and
@z should still get both items.
Right? Or am I completely missing something important here?
My current plan is to write such tests as
sub l { 1, 2 } # return a short list
{
my @a;
my @z = (@a[0] = l(), l());
is @a[0].elems, 4, '@a[0] = treats LHS as list'
is @z.elems, 4, '... and passes all elements on the right';
}
Does this look sane, and match your understanding of assignment?
Cheers,
Moritz
