Make list assignment to sub :lvalue{keys} an error

[p5pRT]

Migrated from rt.perl.org#128187 (status was 'resolved')

Searchable as RT128187$

[p5pRT]

From @cpansprout

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

[p5pRT]

From @cpansprout

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 a061ab0 and 738155d.

--

Father Chrysostomos

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

@cpansprout - Status changed from 'open' to 'resolved'

[p5pRT]

From @demerphq

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​:

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 a061ab0 and 738155d.

--

Father Chrysostomos

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