Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
p5pRT opened this issue May 19, 2016 · 5 comments
Closed

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

p5pRT opened this issue May 19, 2016 · 5 comments

Comments

@p5pRT
Copy link

p5pRT commented May 19, 2016

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

Searchable as RT128187$

@p5pRT
Copy link
Author

p5pRT commented May 19, 2016

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
Copy link
Author

p5pRT commented May 20, 2016

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
Copy link
Author

p5pRT commented May 20, 2016

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

@p5pRT
Copy link
Author

p5pRT commented May 20, 2016

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

@p5pRT p5pRT closed this as completed May 20, 2016
@p5pRT
Copy link
Author

p5pRT commented May 21, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant