[PATCH] Accept lvalue subroutines as a useful feature.

[p5pRT]

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

Searchable as RT91648$

[p5pRT]

From @sciurius

Support for lvalue subroutines has been stable and reliable for more than 10 years. Despite this\, they are still marked as being experimental.

This patch removes the 'experimental' warnings from the docs\, and adjusts the description accordingly.

---

pod/perlsub.pod | 38 +++++++++----------------------------- 1 files changed\, 9 insertions(+)\, 29 deletions(-)

[p5pRT]

From @sciurius

0001-Accept-lvalue-subroutines-as-a-useful-feature.patch

```diff diff --git a/pod/perlsub.pod b/pod/perlsub.pod index 81dbfa1..d014d7e 100644 --- a/pod/perlsub.pod +++ b/pod/perlsub.pod @@ -732,15 +732,12 @@ also accepted. =head2 Lvalue subroutines X X -B: Lvalue subroutines are still experimental and the -implementation may change in future versions of Perl. - It is possible to return a modifiable value from a subroutine. To do this, you have to declare the subroutine to return an lvalue. my $val; sub canmod : lvalue { - # return $val; this doesn't work, don't say "return" + # don't say "return" $val; } sub nomod { @@ -766,38 +763,21 @@ and in: all the subroutines are called in a list context. -=over 4 - -=item Lvalue subroutines are EXPERIMENTAL - -They appear to be convenient, but there are several reasons to be -circumspect. +Lvalue subroutines are convenient, but there are some things to keep +in mind. You can't use the return keyword, you must pass out the value before falling out of subroutine scope. (see comment in example above). This is usually not a problem, but it disallows an explicit return out of a deeply nested loop, which is sometimes a nice way out. -They violate encapsulation. A normal mutator can check the supplied -argument before setting the attribute it is protecting, an lvalue -subroutine never gets that chance. Consider; - - my $some_array_ref = []; # protected by mutators ?? +When used with objects, they violate encapsulation. A normal mutator +can check the supplied argument before setting the attribute it is +protecting, an lvalue subroutine cannot. - sub set_arr { # normal mutator - my $val = shift; - die("expected array, you supplied ", ref $val) - unless ref $val eq 'ARRAY'; - $some_array_ref = $val; - } - sub set_arr_lv : lvalue { # lvalue mutator - $some_array_ref; - } - - # set_arr_lv cannot stop this ! - set_arr_lv() = { a => 1 }; - -=back +Lvalue subroutines are most valuable to contruct simple data +structures that do not require any special processing when storing and +retrieving the values. =head2 Passing Symbol Table Entries (typeglobs) X X<*> ```

[p5pRT]

From @obra

On Wed\, May 25\, 2011 at 02​:49​:11PM -0700\, Johan Vromans wrote​:

# New Ticket Created by Johan Vromans # Please include the string​: [perl #91648] # in the subject line of all future correspondence about this issue. # \<URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=91648 >

Support for lvalue subroutines has been stable and reliable for more than 10 years. Despite this\, they are still marked as being experimental.

This patch removes the 'experimental' warnings from the docs\, and adjusts the description accordingly.

Please do not apply this yet. Marking something as not-experimental actually wants discussion.

I don't expect there to be a reason not to apply it\, but I'd like to see it discussed and to give people an opportunity to comment.

-Jesse

[p5pRT]

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

[p5pRT]

From @chipdude

On 5/25/2011 4​:20 PM\, Jesse Vincent wrote​:

I don't expect there to be a reason not to apply it\, but I'd like to see it discussed and to give people an opportunity to comment.

I have a reason​: There is no support for list lvalues.

[p5pRT]

From @ikegami

On Wed\, May 25\, 2011 at 7​:20 PM\, Jesse Vincent \jesse@&#8203;fsck\.com wrote​:

Please do not apply this yet. Marking something as not-experimental actually wants discussion.

At this point\, can lvalue subs be changed without deprecation/feature? If not\, I don't think there's any point in marking them experimental.

- Eric

[p5pRT]

From @sciurius

Reverend Chip \rev\.chip@&#8203;gmail\.com writes​:

On 5/25/2011 4​:20 PM\, Jesse Vincent wrote​:

I don't expect there to be a reason not to apply it\, but I'd like to see it discussed and to give people an opportunity to comment.

I have a reason​: There is no support for list lvalues.

Good point. Fortunately\, this is clearly documented.

Having list lvalue subs would be a nice extension\, though.

-- Johan

[p5pRT]

From @sciurius

Eric Brine \ikegami@&#8203;adaelis\.com writes​:

At this point\, can lvalue subs be changed without deprecation/feature?

I don't think so. Deprecation/Feature will break existing code.

If not\, I don't think there's any point in marking them experimental.

Exactly.

-- Johan

[p5pRT]

From @abigail

On Wed\, May 25\, 2011 at 07​:20​:35PM -0400\, Jesse Vincent wrote​:

On Wed\, May 25\, 2011 at 02​:49​:11PM -0700\, Johan Vromans wrote​:

# New Ticket Created by Johan Vromans # Please include the string​: [perl #91648] # in the subject line of all future correspondence about this issue. # \<URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=91648 >

Support for lvalue subroutines has been stable and reliable for more than 10 years. Despite this\, they are still marked as being experimental.

This patch removes the 'experimental' warnings from the docs\, and adjusts the description accordingly.

Please do not apply this yet. Marking something as not-experimental actually wants discussion.

I don't expect there to be a reason not to apply it\, but I'd like to see it discussed and to give people an opportunity to comment.

Not a disccusing about this particular feature\, but about having something marked experimental for that long.

Lvalue subroutines have been part of Perl for so long\, I didn't even realize it as still marked experimental (By the time 5.16 is out\, they've been part of Perl for 12 years - and by that time\, Perl itself is 24.5 years old).

IMO. keeping features marked as 'experimental' for that long makes the entire experimental label not useful. Do we really want to reserve the right to change/delete features that have been with us since the previous century\, without any deprecation cycle? Do we really expect to people to remember what's experimental for that long? And if we're going to use a deprecation cycle\, what's the point of having an experimental label for so long?

I'd say that if something is introduced as "experimental"\, but it remains unchanged for 2 major releases\, it should be considered part of the language. I bet you\, that's what Joe R. Programmer does.

Abigail

[p5pRT]

From @jandubois

On Thu\, 26 May 2011\, Johan Vromans wrote​:

Eric Brine \ikegami@&#8203;adaelis\.com writes​:

At this point\, can lvalue subs be changed without deprecation/feature?

I don't think so. Deprecation/Feature will break existing code.

Yes\, but that is acceptable for experimental features (please see perlpolicy.pod). This really is the only point of marking something as experimental​: that it can be changed\, or even removed at will.

If not\, I don't think there's any point in marking them experimental.

Exactly.

Sure\, but that's a tautology​: If it isn't experimental\, then it isn't.

Please note that I'm not arguing for the deprecation of lvalue subs; I'm just a bit annoyed by intentional ignorance of existing policies.

If you think the policy about experimental status is wrong\, then I would like you to propose a change to that *first* [1]. Or if you think things should always be decided ad-hoc\, then maybe it is better to stop attempting to formulate a policy in the first place (in which case I would strongly disagree).

Cheers\, -Jan

[1] E.g. propose that an experimental feature should either be removed   (or at least disabled) in the next major release\, or approved as a   supported feature. I'm not sure this is better than the status quo\,   but it also isn't unreasonable either.

[p5pRT]

From @Leont

On Thu\, May 26\, 2011 at 10​:10 AM\, Abigail \abigail@&#8203;abigail\.be wrote​:

Not a disccusing about this particular feature\, but about having something marked experimental for that long.

Lvalue subroutines have been part of Perl for so long\, I didn't even realize it as still marked experimental (By the time 5.16 is out\, they've been part of Perl for 12 years - and by that time\, Perl itself is 24.5 years old).

IMO. keeping features marked as 'experimental' for that long makes the entire experimental label not useful. Do we really want to reserve the right to change/delete features that have been with us since the previous century\, without any deprecation cycle? Do we really expect to people to remember what's experimental for that long? And if we're going to use a deprecation cycle\, what's the point of having an experimental label for so long?

I'd say that if something is introduced as "experimental"\, but it remains unchanged for 2 major releases\, it should be considered part of the language. I bet you\, that's what Joe R. Programmer does.

I agree. I think it would be wise to evaluate all experimental features and functions before every stable release\, and decide what to do about that. I don't think we even have a list of experimental features right now.

Leon

[p5pRT]

From @epa

Maybe future experimental features should be conditional on

  use experimental;

or something more specific.

Indeed\, if the policy on experimental features is that they can be changed\, all existing ones could be changed to require this declaration.

-- Ed Avis \eda@&#8203;waniasset\.com

[p5pRT]

From @obra

On Thu\, May 26\, 2011 at 10​:10​:00AM +0200\, Abigail wrote​:

IMO. keeping features marked as 'experimental' for that long makes the entire experimental label not useful. Do we really want to reserve the right to change/delete features that have been with us since the previous century\, without any deprecation cycle? Do we really expect to people to remember what's experimental for that long? And if we're going to use a deprecation cycle\, what's the point of having an experimental label for so long?

This is almost exactly the same problem we ran into with deprecated features not warning by default until 5.12.

I can guarantee you that we won't be simply removing lvalue subs (or breaking their syntax or semantics in existing code) for 5.16.

I'd say that if something is introduced as "experimental"\, but it remains unchanged for 2 major releases\, it should be considered part of the language. I bet you\, that's what Joe R. Programmer does.

Apathy-driven language design scares me. I agree 100% with your problem statement\, but we have to come up with a better solution.

-Jesse

[p5pRT]

From @nwc10

I agree that there is a problem here with experimental features.

On Thu\, May 26\, 2011 at 10​:10​:00AM +0200\, Abigail wrote​:

On Wed\, May 25\, 2011 at 07​:20​:35PM -0400\, Jesse Vincent wrote​:

On Wed\, May 25\, 2011 at 02​:49​:11PM -0700\, Johan Vromans wrote​:

Support for lvalue subroutines has been stable and reliable for more

I don't agree with the "reliable" part.

I didn't have to poke very hard last year to find several bugs. (Although I don't know if Father Chrysostomos has now fixed most that I reported)

I stopped trying to poke when it became clear that there was a whole can of worms within.

I don't expect there to be a reason not to apply it\, but I'd like to see it discussed and to give people an opportunity to comment.

Not a disccusing about this particular feature\, but about having something marked experimental for that long.

IMO. keeping features marked as 'experimental' for that long makes the entire experimental label not useful. Do we really want to reserve the right to change/delete features that have been with us since the previous century\, without any deprecation cycle? Do we really expect to people to remember what's experimental for that long? And if we're going to use a deprecation cycle\, what's the point of having an experimental label for so long?

I'd say that if something is introduced as "experimental"\, but it remains unchanged for 2 major releases\, it should be considered part of the language. I bet you\, that's what Joe R. Programmer does.

Serious bugs and all?

Going forwards\, yes\, no new experimental features unless they get finished\, or killed.

But trying to apply that rule retroactively just with documentation changes would also mean that (?{}) code blocks in regular expressions would be deemed sane. When their handling of lexicals is deeply flawed.

(Curiously\, I believe that the author of both of these incomplete features is the same person)

So yes\, I'd like to see the list of all features still considered experimental. And then work out what's still incomplete about them\, and what is going to be done to fix that.

Nicholas Clark

[p5pRT]

From @dgl

On 25 May 2011\, at 22​:49\, Johan Vromans (via RT) wrote​:

Support for lvalue subroutines has been stable and reliable for more than 10 years. Despite this\, they are still marked as being experimental.

The meta ticket on lvalue subs paints a slightly less rosy picture​: http​://rt.perl.org/rt3//Public/Bug/Display.html?id=89650

Father Chrysostomos's comment here is particularly relevant too​: http​://rt.perl.org/rt3/Public/Bug/Display.html?id=72724#txn-769292

[p5pRT]

From @ikegami

On Thu\, May 26\, 2011 at 4​:17 AM\, Jan Dubois \jand@&#8203;activestate\.com wrote​:

On Thu\, 26 May 2011\, Johan Vromans wrote​:

Eric Brine \ikegami@&#8203;adaelis\.com writes​:

At this point\, can lvalue subs be changed without deprecation/feature?

I don't think so. Deprecation/Feature will break existing code.

Yes\, but that is acceptable for experimental features (please see perlpolicy.pod).

In general\, yes. I'm asking about this specific case. Even though it could be changed without warning by policy\, is that something we can really do without pissing of Perl's users.

Please note that I'm not arguing for the deprecation of lvalue subs;

I'm just a bit annoyed by intentional ignorance of existing policies.

Not the case at all.

If you think the policy about experimental status is wrong\, then I would like you to propose a change to that *first* [1].

I'm only questioning the experimental status of lvalue subs. If we can't safely remove/change them without pissing Perl's user base\, they're no longer experimental.

- Eric

[p5pRT]

From @chipdude

On 5/26/2011 10​:39 AM\, Eric Brine wrote​:

If we can't safely remove/change them without pissing Perl's user base\, they're no longer experimental.

Some users will be pissed of course; the question is\, how many? My back-of-the-envelope estimate is... not enough to worry about. The wise ones honored the "experimental" label and don't count on it. The foolish ones were going to get mad about something else eventually anyway.

[p5pRT]

From @ikegami

On Thu\, May 26\, 2011 at 1​:48 PM\, Reverend Chip \rev\.chip@&#8203;gmail\.com wrote​:

On 5/26/2011 10​:39 AM\, Eric Brine wrote​:

If we can't safely remove/change them without pissing Perl's user base\, they're no longer experimental.

Some users will be pissed of course; the question is\, how many?

Of course. That's why I said "user base"\, not "some users".

Based on the limited usefulness of lvalues subs as they stand\, and based on Nicholas's and David Leadbeate's comments\, the number is probably small.

[p5pRT]

From @tsee

On 05/26/2011 10​:10 AM\, Abigail wrote​:

I'd say that if something is introduced as "experimental"\, but it remains unchanged for 2 major releases\, it should be considered part of the language. I bet you\, that's what Joe R. Programmer does.

Considered part of the language or forcefully removed by policy. I think the important part is to enforce a decision.

--Steffen

[p5pRT]

From @cpansprout

On Wed May 25 14​:49​:11 2011\, jv wrote​:

Support for lvalue subroutines has been stable and reliable for more than 10 years. Despite this\, they are still marked as being experimental.

This patch removes the 'experimental' warnings from the docs\, and adjusts the description accordingly.

I like the idea\, but it would be nice if you could correct this paragraph\, too​:

You can't use the return keyword\, you must pass out the value before falling out of subroutine scope. (see comment in example above). This is usually not a problem\, but it disallows an explicit return out of a deeply nested loop\, which is sometimes a nice way out.

You *can* use the return keyword. Or at least *now* you can. ;-)

Previously it was possible\, but only if one replaced ‘return $x’ with​:

return sub { delete $_[0] }->($x)

:-)

References​: http​://perl5.git.perl.org/perl.git/commitdiff/fa1e92c http​://rt.perl.org/rt3/Ticket/Display.html?id=91844

[p5pRT]

From @sciurius

I like the idea\, but it would be nice if you could correct this paragraph\, too​:

Sure. Take #2 attached.

References​: http​://perl5.git.perl.org/perl.git/commitdiff/fa1e92c http​://rt.perl.org/rt3/Ticket/Display.html?id=91844

[p5pRT]

From @sciurius

0001-Accept-lvalue-subroutines-as-a-useful-feature.patch

```diff From 7e350fdca41e833a317de555313ca67ae6a55157 Mon Sep 17 00:00:00 2001 From: Johan Vromans Date: Mon, 30 May 2011 08:03:03 +0200 Subject: [PATCH] Accept lvalue subroutines as a useful feature. Bcc: jvromans@squirrel.nl To: perlbug@perl.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------1.7.4.4" This is a multi-part message in MIME format. --------------1.7.4.4 Content-Type: text/plain; charset=UTF-8; format=fixed Content-Transfer-Encoding: 8bit Support for lvalue subroutines has been stable and reliable for more than 10 years. Despite this, they are still marked as being experimental. This patch removes the 'experimental' warnings from the docs, and adjusts the description accordingly. --- pod/perlsub.pod | 44 ++++++++++---------------------------------- 1 files changed, 10 insertions(+), 34 deletions(-) --------------1.7.4.4 Content-Type: text/x-patch; name="0001-Accept-lvalue-subroutines-as-a-useful-feature.patch" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="0001-Accept-lvalue-subroutines-as-a-useful-feature.patch" diff --git a/pod/perlsub.pod b/pod/perlsub.pod index 81dbfa1..54f782c 100644 --- a/pod/perlsub.pod +++ b/pod/perlsub.pod @@ -732,16 +732,12 @@ also accepted. =head2 Lvalue subroutines X X -B: Lvalue subroutines are still experimental and the -implementation may change in future versions of Perl. - It is possible to return a modifiable value from a subroutine. To do this, you have to declare the subroutine to return an lvalue. my $val; sub canmod : lvalue { - # return $val; this doesn't work, don't say "return" - $val; + $val; # or "return $val;" } sub nomod { $val; @@ -766,38 +762,18 @@ and in: all the subroutines are called in a list context. -=over 4 - -=item Lvalue subroutines are EXPERIMENTAL - -They appear to be convenient, but there are several reasons to be -circumspect. - -You can't use the return keyword, you must pass out the value before -falling out of subroutine scope. (see comment in example above). This -is usually not a problem, but it disallows an explicit return out of a -deeply nested loop, which is sometimes a nice way out. +Lvalue subroutines are convenient, but there are some things to keep +in mind. -They violate encapsulation. A normal mutator can check the supplied -argument before setting the attribute it is protecting, an lvalue -subroutine never gets that chance. Consider; +You can only return scalar lvalues. - my $some_array_ref = []; # protected by mutators ?? +When used with objects, they violate encapsulation. A normal mutator +can check the supplied argument before setting the attribute it is +protecting, an lvalue subroutine cannot. - sub set_arr { # normal mutator - my $val = shift; - die("expected array, you supplied ", ref $val) - unless ref $val eq 'ARRAY'; - $some_array_ref = $val; - } - sub set_arr_lv : lvalue { # lvalue mutator - $some_array_ref; - } - - # set_arr_lv cannot stop this ! - set_arr_lv() = { a => 1 }; - -=back +Lvalue subroutines are most valuable to contruct simple data +structures that do not require any special processing when storing and +retrieving the values. =head2 Passing Symbol Table Entries (typeglobs) X X<*> --------------1.7.4.4-- ```

[p5pRT]

From @cpansprout

On Sun May 29 23​:18​:53 2011\, jv wrote​:

I like the idea\, but it would be nice if you could correct this paragraph\, too​:

Sure. Take #2 attached.

Thank you. Applied as c72c0c0.

[p5pRT]

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

[p5pRT]

From @cpansprout

On Wed May 25 16​:45​:43 2011\, rev.chip@​gmail.com wrote​:

On 5/25/2011 4​:20 PM\, Jesse Vincent wrote​:

I don't expect there to be a reason not to apply it\, but I'd like to see it discussed and to give people an opportunity to comment.

I have a reason​: There is no support for list lvalues.

Really? They work for me.

[p5pRT]

From @cpansprout

On Tue May 31 20​:02​:09 2011\, sprout wrote​:

On Wed May 25 16​:45​:43 2011\, rev.chip@​gmail.com wrote​:

On 5/25/2011 4​:20 PM\, Jesse Vincent wrote​:

I don't expect there to be a reason not to apply it\, but I'd like to see it discussed and to give people an opportunity to comment.

I have a reason​: There is no support for list lvalues.

Really? They work for me.

See commit 84615ddc63ad.

[p5pRT]

From @cpansprout

On Tue May 31 20​:01​:23 2011\, sprout wrote​:

On Sun May 29 23​:18​:53 2011\, jv wrote​:

I like the idea\, but it would be nice if you could correct this paragraph\, too​:

Sure. Take #2 attached.

Thank you. Applied as c72c0c0.

Jesse asked me to revert it for now\, which I’ve done with commit 4051c94.

[p5pRT]

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

[p5pRT]

From @sciurius

Jesse asked me to revert it for now\, which I’ve done with commit 4051c94.

It was worth trying.

[p5pRT]

From @chipdude

On 5/31/2011 8​:26 PM\, Father Chrysostomos via RT wrote​:

On Tue May 31 20​:02​:09 2011\, sprout wrote​:

On Wed May 25 16​:45​:43 2011\, rev.chip@​gmail.com wrote​:

On 5/25/2011 4​:20 PM\, Jesse Vincent wrote​:

I don't expect there to be a reason not to apply it\, but I'd like to see it discussed and to give people an opportunity to comment. I have a reason​: There is no support for list lvalues.

Really? They work for me. See commit 84615ddc63ad.

Oh\, that? That doesn't count.

$ ./miniperl -Ilib   sub foo : lvalue { @​a }   foo() = (1\,2\,3);   print "@​a\n"; Can't return array to lvalue scalar context at - line 1.

[p5pRT]

From @sciurius

[Quoting Reverend Chip via RT\, on June 4 2011\, 16​:10\, in "Re​: [perl #91648] [P"]

Oh\, that? That doesn't count.

$ ./miniperl -Ilib sub foo : lvalue { @​a } foo() = (1\,2\,3); print "@​a\n"; Can't return array to lvalue scalar context at - line 1.

No problem to restrict lvalue subs to scalar only.

I think all lvalue builtins are also scalar only.

  my $a = "xyz";   substr($a\,1\,1) = ("noot"\,"mies");   say $a; # prints xmiesy

-- Johan

[p5pRT]

From @cpansprout

On Sun Jun 05 01​:05​:47 2011\, jv wrote​:

[Quoting Reverend Chip via RT\, on June 4 2011\, 16​:10\, in "Re​: [perl #91648] [P"]

Oh\, that? That doesn't count.

$ ./miniperl -Ilib sub foo : lvalue { @​a } foo() = (1\,2\,3); print "@​a\n"; Can't return array to lvalue scalar context at - line 1.

‘(foo) = ...’ calls the function in list context\, but I think you already knew that.

How is Perl supposed to know that that function provides list context to the lhs of an assignment?

If we are to do that\, we need some way to specify it other than having Perl guess based on the last statement in a manner similar to when. Maybe if :llvalue has been seen already at compile-time that could work (a bit like prototypes). Or maybe it could be included in the prototype\, but I think that’s stretching prototypes too far. Maybe :list should be a separate attribute. Then it could also apply to x.

No problem to restrict lvalue subs to scalar only.

I don’t think we should eliminate list context.

[p5pRT]

From ebhanssen@cpan.org

On Sun\, Jun 5\, 2011 at 11​:44 PM\, Father Chrysostomos via RT \< perlbug-followup@​perl.org> wrote​:

On Sun Jun 05 01​:05​:47 2011\, jv wrote​:

[Quoting Reverend Chip via RT\, on June 4 2011\, 16​:10\, in "Re​: [perl #91648] [P"]

Oh\, that? That doesn't count.

$ ./miniperl -Ilib sub foo : lvalue { @​a } foo() = (1\,2\,3); print "@​a\n"; Can't return array to lvalue scalar context at - line 1.

‘(foo) = ...’ calls the function in list context\, but I think you already knew that.

How is Perl supposed to know that that function provides list context to the lhs of an assignment?

  Only (...) = ...\, @​... = ...\, and %... = ... are list assignments\, right? All other assignment operators and all other left-hand-sides yield scalar assignment?

  How about just documenting this for all time\, and let all other attempted "list" assignments remain errors?

  ... or would that be insufficient hubris? :-\

Eirik

[p5pRT]

From @ikegami

On Sun\, Jun 5\, 2011 at 6​:16 PM\, Eirik Berg Hanssen \ebhanssen@&#8203;cpan\.org wrote​:

 Only (...) = ...\, @​... = ...\, and %... = ... are list assignments\, right?

All other assignment operators and all other left-hand-sides yield scalar assignment?

@​array %hash (...) my (...)\, our (...) and local (...)\, slices ( @​array[...]\, @​hash{...} and (...)[...] )

[p5pRT]

From ebhanssen@cpan.org

On Mon\, Jun 6\, 2011 at 11​:44 PM\, Eric Brine \ikegami@&#8203;adaelis\.com wrote​:

On Sun\, Jun 5\, 2011 at 6​:16 PM\, Eirik Berg Hanssen \ebhanssen@&#8203;cpan\.org wrote​:

Only (...) = ...\, @​... = ...\, and %... = ... are list assignments\, right?

All other assignment operators and all other left-hand-sides yield scalar assignment?

@​array %hash (...)

  Yup.

my (...)\, our (...) and local (...)\,

  In my mind\, if perhaps somewhat inaccurately\, these are variations on the (...) = ... theme. All the more inaccurately for state (...) = .... not being quite list assignment\, or even allowed.

  So\, yeah\, in documentation I suppose they need to be mentioned separately.

slices ( @​array[...]\, @​hash{...} and (...)[...] )

  Actually\, I think this one is scalar​: (...)[...] = ... – and even in list assignment\, a list slice is not an lvalue​:

sidhekin@​bluebird[06​:53​:48]~$ perl -le 'my ($x\, $y\, $z); ($y\, $x\, $z)[2\,0] = 1..2; print "$x-$y-$z";' Can't modify list slice in scalar assignment at -e line 1\, near "2;" Execution of -e aborted due to compilation errors. sidhekin@​bluebird[06​:53​:49]~$ perl -le 'my ($x\, $y\, $z); (($y\, $x\, $z)[2\,0]) = 1..2; print "$x-$y-$z";' Can't modify list slice in list assignment at -e line 1\, near "2;" Execution of -e aborted due to compilation errors. sidhekin@​bluebird[06​:53​:56]~$

  The other ones are in my mind variations on @​... = .... And that's not so inaccurately\, is it?

  (And then there are various derefs​: @​{...} = ...; %{...} = ...; @​$... = ...; %$... = ...; &c. In my mind\, these are variations on @​... = ... and %... = ....)

Eirik

[p5pRT]

From @ikegami

On Tue\, Jun 7\, 2011 at 1​:16 AM\, Eirik Berg Hanssen \ebhanssen@&#8203;cpan\.org wrote​:

On Mon\, Jun 6\, 2011 at 11​:44 PM\, Eric Brine \ikegami@&#8203;adaelis\.com wrote​:

my (...)\, our (...) and local (...)\,

 In my mind\, if perhaps somewhat inaccurately\, these are variations on the (...) = ... theme.

Except the relation you are trying to document\, there's no relation between "expressions in parenthesis"\, list variable declerators my() and our()\, and list variable localiser local().

 Actually\, I think this one is scalar​: (...)[...] = ... – and even in list assignment\, a list slice is not an lvalue​:

It's capable of returning a list\, but I stand corrected about it causing the selection of the list assignment operator. I updated my source. [http​://www.perlmonks.org/?node_id=790129]

 The other [slices] are in my mind variations on @​... = ....  And that's not so inaccurately\, is it?

Slices are different operators than @​a and %h\, and they are documented separately in perldata.

 (And then there are various derefs​: @​{...} = ...; %{...} = ...; @​$... = ...; %$... = ...; &c.  In my mind\, these are variations on @​... = ... and %... = ....)

I concur\, which is why I didn't mention them.

[p5pRT]

From @cpansprout

On Tue May 31 23​:14​:33 2011\, jv wrote​:

Jesse asked me to revert it for now\, which I’ve done with commit 4051c94.

It was worth trying.

It doesn’t apply cleanly any more. Could you update it again?

--

Father Chrysostomos

[p5pRT]

From @sciurius

0001-Update-perlsub.pod-for-lvalue-subroutines.patch

```diff From 26df81d19b15c74d122ce2c07ccff4a89103b170 Mon Sep 17 00:00:00 2001 From: Johan Vromans Date: Fri, 21 Jun 2013 17:31:54 +0200 Subject: [PATCH] Update perlsub.pod for lvalue subroutines. --- pod/perlsub.pod | 36 ++++++++---------------------------- 1 file changed, 8 insertions(+), 28 deletions(-) diff --git a/pod/perlsub.pod b/pod/perlsub.pod index 027d7be..b33af66 100644 --- a/pod/perlsub.pod +++ b/pod/perlsub.pod @@ -764,9 +764,6 @@ also accepted. =head2 Lvalue subroutines X X -B: Lvalue subroutines are still experimental and the -implementation may change in future versions of Perl. - It is possible to return a modifiable value from a subroutine. To do this, you have to declare the subroutine to return an lvalue. @@ -797,33 +794,16 @@ and in: all the subroutines are called in a list context. -=over 4 - -=item Lvalue subroutines are EXPERIMENTAL - -They appear to be convenient, but there is at least one reason to be -circumspect. - -They violate encapsulation. A normal mutator can check the supplied -argument before setting the attribute it is protecting, an lvalue -subroutine never gets that chance. Consider; +Lvalue subroutines are convenient, but there are two things to keep in +mind. - my $some_array_ref = []; # protected by mutators ?? +First, you can only return scalar lvalues. - sub set_arr { # normal mutator - my $val = shift; - die("expected array, you supplied ", ref $val) - unless ref $val eq 'ARRAY'; - $some_array_ref = $val; - } - sub set_arr_lv : lvalue { # lvalue mutator - $some_array_ref; - } - - # set_arr_lv cannot stop this ! - set_arr_lv() = { a => 1 }; - -=back +Second, when used with objects, they violate encapsulation. A normal +mutator can check the supplied argument before setting the attribute +it is protecting, an lvalue subroutine cannot. If you require any +special processing when storing and retrieving the values, consider +using the CPAN module Sentinel or something similar. =head2 Lexical Subroutines X X X X -- 1.7.11.7 ```

[p5pRT]

From @cpansprout

On Fri Jun 21 08​:34​:10 2013\, jv wrote​:

+First\, you can only return scalar lvalues.

Sorry for not noticing this earlier. Actually\, you *can* return list lvalues\, but the subroutine itself must be in list context\, which is accomplished through parentheses (func)=....

Commit 84615ddc63 (or something) made this work. That was the subject of ticket #5005.

--

Father Chrysostomos

[p5pRT]

From @sciurius

0001-Update-perlsub.pod-for-lvalue-subroutines.patch

```diff From 5a2ad2a5ab80d85830805a207c3c200db5969487 Mon Sep 17 00:00:00 2001 From: Johan Vromans Date: Fri, 21 Jun 2013 17:31:54 +0200 Subject: [PATCH] Update perlsub.pod for lvalue subroutines. --- pod/perlsub.pod | 36 ++++++------------------------------ 1 file changed, 6 insertions(+), 30 deletions(-) diff --git a/pod/perlsub.pod b/pod/perlsub.pod index 027d7be..8a6ea6e 100644 --- a/pod/perlsub.pod +++ b/pod/perlsub.pod @@ -764,9 +764,6 @@ also accepted. =head2 Lvalue subroutines X X -B: Lvalue subroutines are still experimental and the -implementation may change in future versions of Perl. - It is possible to return a modifiable value from a subroutine. To do this, you have to declare the subroutine to return an lvalue. @@ -797,33 +794,12 @@ and in: all the subroutines are called in a list context. -=over 4 - -=item Lvalue subroutines are EXPERIMENTAL - -They appear to be convenient, but there is at least one reason to be -circumspect. - -They violate encapsulation. A normal mutator can check the supplied -argument before setting the attribute it is protecting, an lvalue -subroutine never gets that chance. Consider; - - my $some_array_ref = []; # protected by mutators ?? - - sub set_arr { # normal mutator - my $val = shift; - die("expected array, you supplied ", ref $val) - unless ref $val eq 'ARRAY'; - $some_array_ref = $val; - } - sub set_arr_lv : lvalue { # lvalue mutator - $some_array_ref; - } - - # set_arr_lv cannot stop this ! - set_arr_lv() = { a => 1 }; - -=back +Lvalue subroutines are convenient, but you have to keep in mind that, +when used with objects, they may violate encapsulation. A normal +mutator can check the supplied argument before setting the attribute +it is protecting, an lvalue subroutine cannot. If you require any +special processing when storing and retrieving the values, consider +using the CPAN module Sentinel or something similar. =head2 Lexical Subroutines X X X X -- 1.7.11.7 ```

[p5pRT]

From @cpansprout

On Fri Jun 21 11​:08​:29 2013\, jv wrote​:

From 5a2ad2a5ab80d85830805a207c3c200db5969487 Mon Sep 17 00​:00​:00 2001 From​: Johan Vromans \jvromans@&#8203;squirrel\.nl Date​: Fri\, 21 Jun 2013 17​:31​:54 +0200 Subject​: [PATCH] Update perlsub.pod for lvalue subroutines.

Thank you. Applied as 771cc7554.

--

Father Chrysostomos

[p5pRT]

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