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

[Ian Jackson]

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.

The comment in the RT ticket that
  As a guideline, don't read a variable in the same expression in
  which it changes.
doesn't seem to me to be accurate.  That also seems to me to show that
the documentation could be improved.

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.

2. The behaviour isn't directly stated, and it should be.

3. Contrary to the assertion in the RT ticket, the problem is not
"read[ing] a variable in the same expression in which it changes".
Indeed if there were a rule against that, it would be necessary to
introduce a notion along the lines of C89's "sequence points" and
document exactly when setting and reading a variable in the "same
expression" is allowed.  For example the assertion in the RT ticket
would forbid
     open F, "filename" or die $!;
since that's one expression whose LHS ("open ...") sets $! and whose
RHS reads it.  So some more subtle and accurate rule is needed.

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 ?

Ian.