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

Explicit use of `return` on `is rw` subs should behave like `return-rw` #5243

Closed
p6rt opened this issue Apr 18, 2016 · 5 comments
Closed

Explicit use of `return` on `is rw` subs should behave like `return-rw` #5243

p6rt opened this issue Apr 18, 2016 · 5 comments
Labels
RFC

Comments

@p6rt
Copy link

@p6rt p6rt commented Apr 18, 2016

Migrated from rt.perl.org#127924 (status was 'rejected')

Searchable as RT127924$

@p6rt
Copy link
Author

@p6rt p6rt commented Apr 18, 2016

From @zoffixznet

Currently, if you use explicit keyword `return` to return out of a sub marked with `is rw` trait, you still get a read-only value, even though you get a read-write one if you omit `return`​:

<ZoffixW> m​: my %h = foo => 'bar'; sub lookup ($key) is rw { return %h{$key}; }; lookup('foo') = 'meow'; say %h;
<camelia> rakudo-moar 1aabef​: OUTPUT«Cannot assign to a readonly variable or a value␤ in block <unit> at /tmp/buNGUMJLYO line 1␤␤»

To rectify this, `return-rw` keyword exists, BUT it doesn't require the sub to have `is rw` trait. Thus, the `is rw` trait's usefulness is narrowed down to only subs that rely on implicit returns. It also produces confusion, since an average programmer would expect explicit placement of keyword `return` to retain the program's behaviour unchanged.

Thus, I propose that when a `return` is called from a sub or method marked with `is rw` trait, `return-rw` should be called instead. This makes the train more useful and its behavour more predictable.

Relevant IRC discussion​: http://irclog.perlgeek.de/perl6/2016-04-18#i_12356836

@p6rt
Copy link
Author

@p6rt p6rt commented May 4, 2016

From @cpansprout

On Mon Apr 18 11​:16​:05 2016, cpan@​zoffix.com wrote​:

Currently, if you use explicit keyword `return` to return out of a sub
marked with `is rw` trait, you still get a read-only value, even
though you get a read-write one if you omit `return`​:

<ZoffixW> m​: my %h = foo => 'bar'; sub lookup ($key) is rw { return
%h{$key}; }; lookup('foo') = 'meow'; say %h;
<camelia> rakudo-moar 1aabef​: OUTPUT«Cannot assign to a readonly
variable or a value␤ in block <unit> at /tmp/buNGUMJLYO line 1␤␤»

To rectify this, `return-rw` keyword exists, BUT it doesn't require
the sub to have `is rw` trait. Thus, the `is rw` trait's usefulness is
narrowed down to only subs that rely on implicit returns. It also
produces confusion, since an average programmer would expect explicit
placement of keyword `return` to retain the program's behaviour
unchanged.

Thus, I propose that when a `return` is called from a sub or method
marked with `is rw` trait, `return-rw` should be called instead. This
makes the train more useful and its behavour more predictable.

Relevant IRC discussion​: http://irclog.perlgeek.de/perl6/2016-04-
18#i_12356836

FWIW, the Perl 5 return keyword works with both lvalue and non-lvalue subs. It checks the attribute on the sub and behaves accordingly.

--

Father Chrysostomos

@p6rt
Copy link
Author

@p6rt p6rt commented May 4, 2016

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

@p6rt
Copy link
Author

@p6rt p6rt commented Jul 10, 2016

From @zoffixznet

Closing due to lack of interest.

@p6rt
Copy link
Author

@p6rt p6rt commented Jul 10, 2016

@zoffixznet - Status changed from 'open' to 'rejected'

@p6rt p6rt closed this Jul 10, 2016
@p6rt p6rt added the RFC label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.