This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
subroutines should be able to return an lvalue
=head1 VERSION
Maintainer: Johan Vromans <[EMAIL PROTECTED]>
Date: Aug 18, 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 132
=head1 ABSTRACT
RFC 107 proposes that lvalue subs should receive their rvalues as
subroutine arguments. RFC 118 counter-proposes that lvalue subs should
receive their rvalues as lexical variables named in a prototype
associated with the :lvalue modifier. This RFC proposes a terrifying
simple solution for the growing complexity of the lvalue subroutines
problem. It proposes the keyword C<lreturn> and discards the <:lvalue>
property.
=head1 DESCRIPTION
If a sub wants to return an lvalue, this lvalue must be a real lvalue
in all respects. In particular, all kinds of implicit and explicit
value changes must be supported. For example,
lvsub() = ...
lvsub() += ...
lvsub() =~ s///
for ( lvsub() ) {
$_ = ...
}
sysread($fh,lvsub(),...)
and so on.
One often heard argument is that subroutines like these must be
callable in either mode:
lvsub(expr)
lvsub() = expr
This argument is false, since the two uses are totally distinct. In
the first case, the sub has control over what it does with the value
while in the lvalue case the sub doesn't -- and doesn't care.
If control is desired, use C<tie>.
The clue is "If a sub wants to return an lvalue, it must B<be> an
lvalue". Therefore I propose a new keyword C<lreturn> that behaves
just like C<return>, but returns the lvalue instead of the rvalue. After
returning, everything is exactly as if the argument to lreturn were
specified instead of the subroutine call. The <:lvalue> property is no
longer needed and should be removed sine it only causes confusion. A
subroutine B<is> not an lvalue thing, it B<returns> an lvalue if it
wants to.
For example:
sub lvsub {
...
lreturn $hash{somekey};
}
lvsub() =~ s/// # identical to $hash{somekey} =~ s///
$ref = \lvsub() # now $ref is \$hash{somekey}
As a thought guide: think of C<lreturn> returning a reference to its
argument, and the call to lvsub() performing a dereference.
With the enhanced C<want> operator, subroutines can dynamically decide
what to return.
Interesting note: you can always use C<lreturn> instead of C<return>;
for rvalue cases it does not matter.
=head1 IMPLEMENTATION
Every subroutine (and method) call can potentially return an lvalue,
so the compiler cannot do smart things. All must be handled at
run-time.
=head1 REFERENCES
RFC 107: lvalue subs should receive the rvalue as an argument
RFC 118: lvalue subs: parameters, explicit assignment, and wantarray() changes
NRETURN, "The SNOBOL4 Programming Language", Griswold & Polonsky.
RFC 21: Replace C<wantarray> with a generic C<want> function
