Skip Menu |
Report information
Id: 128187
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors:
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)



Subject: Make list assignment to sub :lvalue{keys} an error
Download (untitled) / with headers
text/plain 1.5k
With the %hash{'key'} syntax, which is not an lvalue, we have an error if it is the last statement in an lvalue sub and the lvalue sub is assigned to. However, if the lvalue sub call is in foreach(...) or referenced by \ we have no error. So, given sub foo :lvalue { %hash{'key'} } the first line is permitted, but the second one dies: \foo; foo = 3; even though these are both variants of lvalue context. I propose extending that to keys() returned from an lvalue sub in a list assignement. Currently, this works: sub foo :lvalue { keys %h } foo = 1024; But this does not die, yet does nothing useful, and is probably a mistake wherever it occurs: sub foo :lvalue { keys %h } (foo) = 1024; # I want this to die. whereas the plain form of list assignment to keys *does* die at compile time: (keys %h) = 1024; # Can't modify keys in list assignment The reason I bring this up is that, with the demise of autoderef, the one thing standing in the way of making &CORE::keys() work is gone, and I am trying to implement it now. It will be much easier to make this behave the same way as a bare keys()-- &CORE::keys(\%h) = 1024; # ok; scalar assignment (&CORE::keys(\%h)) = 1024; # not ok; list assignment --if I can disallow keys in the circumstance described above. After all, &CORE::keys will be an lvalue sub with ‘keys’ (or the next best thing) as the last op. I intend to go ahead and make this change soon (whatever soon means), but you still have until next year’s code freeze to object. :-) -- Father Chrysostomos
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 302b
On Thu May 19 11:30:35 2016, sprout wrote: Show quoted text
> But this does not die, yet does nothing useful, and is probably a > mistake wherever it occurs: > > sub foo :lvalue { keys %h } > (foo) = 1024; # I want this to die.
I have made this change in commits a061ab0bf and 738155d2fb1. -- Father Chrysostomos
CC: Perl5 Porteros <perl5-porters [...] perl.org>
To: Perl RT Bug Tracker <perlbug-followup [...] perl.org>
Subject: Re: [perl #128187] Make list assignment to sub :lvalue{keys} an error
From: demerphq <demerphq [...] gmail.com>
Date: Sat, 21 May 2016 09:10:17 -0700
Download (untitled) / with headers
text/plain 695b

I think long term we should deprecate assignment to keys. It is a fundamental violation of associative array abstraction.  Imo it should be replaced by a function in hash util.

On 20 May 2016 3:58 p.m., "Father Chrysostomos via RT" <perlbug-followup@perl.org> wrote:
Show quoted text
On Thu May 19 11:30:35 2016, sprout wrote:
> But this does not die, yet does nothing useful, and is probably a
> mistake wherever it occurs:
>
> sub foo :lvalue { keys %h }
> (foo) = 1024;  # I want this to die.

I have made this change in commits a061ab0bf and 738155d2fb1.

--

Father Chrysostomos


---
via perlbug:  queue: perl5 status: new
https://rt.perl.org/Ticket/Display.html?id=128187


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org