Bug#627613: Mistaken aliasing of $& somewhere in the bowels of Perl

[Niko Tyni]

On Sat, Jun 04, 2011 at 06:05:48PM +0100, Ian Jackson wrote:
> Niko Tyni writes ("Re: Bug#627613: Mistaken aliasing of $& somewhere in the bowels of Perl"):
> > That sanity check didn't help much. I filed this upstream but
> > it turns out things are working as intended. See
> >  http://rt.perl.org/rt3/Public/Bug/Display.html?id=92164
> 
> Thanks.  I have to say that I find this quite a surprising
> explanation, but after having read it I can see what's going on.
> 
> However I think these issues should be better explained in the
> documentation.  As far as I can see it's not mentioned in perltrap,
> perlop, perlsyn or perldata.  perldata does have some discussion of
> lists of lvalues which if you squint does sort of imply the
> consequence we see here but it's not explicit and not clear.

[...]

> 1. Arguably this behaviour is wrong when the => operator is involved.
> Since lists including => operators are not generally intended for use
> as lvalues, but rather as initialisers.  But that's probably best
> dealt with as a serparate issue.

Please note that the fat comma operator '=>' is just syntactical sugar and
can be used for lvalues as well. I doubt upstream wants lists to behave
differently depending on whether a regular comma or a fat one was used.

> I would argue that the real problem here is unexpected aliasing.  The
> correct fix is be to introduce language in the discussion of list
> construction in perldata(1) which explains about the delayed
> dereferencing, and warns about unexpected aliasing.  It could usefully
> be mentioned in perltrap(1) too.
> 
> Do you agree ?

I agree that the documentation could be more explicit about this, and
your suggestions sound sane (apart from point 1, as commented above.)

However, I don't see much value in having us (the perl Debian maintainers)
as a proxy here. Please discuss this upstream.

I have to say, though, that upstream strongly prefers documentation
patches over wishlist bugs for documentation changes.
-- 
Niko Tyni   ntyni at debian.org