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
