On Sun Dec 18 03:28:14 2011, SPROUT wrote:
Show quoted text> On Sat Dec 17 21:15:45 2011, ASG wrote:
> > On Thu Dec 15 15:39:14 2011, ANDK wrote:
> >
> > Is this considered a problem with the new functionality introduced
> in
> > bleed perl or with List::Gen?
> >
> > From what I can tell, the problem is originating from line 3334 of
> > List/Gen.pm:
> >
> > local *_ = $from ? $list[-1] :
> > $source ? \$source->(undef, scalar @list) :
> > \scalar @list;
> >
> > Any idea what the behavior change in bleed would have done to this?
> I
> > wouldn't think that propagating lvalueness could cause the value to
> > become undefined.
>
> Ouch! I think I see what’s happening. Propagating lvalueness to
> @list is probably making
> @list return an AV (the array itself). (That’s the way list
> assignment works. The rv2av
> operator, i.e., @foo or @{...}, flattens the array in rvalue context,
> but returns the array itself in
> lvalue context, as in @foo = ..., or in ref context, as in \@list.)
My hunch was close, but my quickly-written description thereof self-contradictory.
What I didn’t know was that \ propagates lvalue context. Trying to fix this is problematic, as
not just \scalar @foo but also \scalar(42, @foo) has to be taken into account.
Furthermore, I was just fixing a bug mentioned in an old ticket (perl #24346), which several
people agreed was a bug, but which I now am beginning to doubt. (If you consider how
defined(scalar @foo) doesn’t work [it’s the same as defined @foo], which is definitely a bug,
then it looks as though fixing *that* bug would require making scalar() act always like a
function. In which case the lvalue bug isn’t really a bug after all.)
So I have reverted it with commit 41b1a11c41 and added tests with commit 544303ee.
RT for rt.cpan.org