[perl #93102] keys is not always an lvalue

On Sun Jun 19 21:37:15 2011, ikegami@adaelis.com wrote:
> On Sun, Jun 19, 2011 at 10:24 PM, Father Chrysostomos <
> perlbug-followup@perl.org> wrote:
> 
> > # New Ticket Created by  Father Chrysostomos
> > # Please include the string:  [perl #93102]
> > # in the subject line of all future correspondence about this issue.
> > # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=93102 >
> >
> >
> > $ perl -le 'read foo, keys %foo, $foo'
> > Can't modify keys in read at -e line 1, at EOF
> > Execution of -e aborted due to compilation errors.
> >
> > Why would you want to do that? You wouldn’t, but it would nice if
> Perl had
> > *some* consistency.
> >
> 
> Maybe it was there to try to avoid problems when lvalue keys used
> TARG.
> Since lvalue keys now returns a fresh scalar, there's no problem
> having two
> keys lvalues in existance, so the lifespan of the lvalue can be
> expanded
> safely.
> 
> 
> > I believe that *deleting* some code in op.c would make this work
> without
> > breaking anything else. (In op_lvalue, the initial if() condition
> under case
> > OP_KEYS.)
> >
> 
> I notice that pos() and vec() don't have this limitation. Go ahead,
> I'd say.

Actually, it would allow keys() assignment in list context, causing this
to be a no-op on empty hashes:

(keys %x) = 42;

So I need to think about this more....

• [perl #93102] keys is not always an lvalue by Father Chrysostomos via RT
• [perl #93102] keys is not always an lvalue by Father Chrysostomos via RT