This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
More defaulting to $_
=head1 VERSION
Maintainer: Kenneth C. Rich <[EMAIL PROTECTED]>
Date: 10 Sep 2000
Last Modified: 13 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 215
Version: 2
Status: Developing
=head1 ABSTRACT
C<$_> is the default variable for some operations and functions.
Other operations would benefit from similar use of
C<$_> to reduce clutter.
=head1 DESCRIPTION
$_ is the default scalar for a small set of operations and functions.
Most of these operations and functions are ones that use C<=~>.
If we decouple C<$_> from C<=~>, then can we profitably use C<$_> elsewhere?
=head2 1: For <>
An inconsistency between "C<print>" and "<>" bugs me: "C<print;>" means
"C<print $_;>" so it seems like "<>" should mean "C<$_ = > <>".
This would break code prompting for "Press any key" and wasting the
input.
Would this have an advantage in making the
while( <> ) {
}
construction less magical?
Actually, some days I wish "C<print;>" meant "print nothing." I was tempted
to title this RFC "Make C<print> and <> consistent."
Problem:
since <> has a different behavior in a list context, does
"C<(> <> C<);>" break, or does it mean something like "C<@_ => <>c<;>" ?
=head2 2: For List Functions
I also would like making "C<push;>" mean C<"push( @_, $_ );>" and
"C<pop;>" mean "C<$_ = pop;>" but I B<can> think of code this would
break. The same wish and problem applies to other list operators. But
maybe the problems are easily fixed with the 5-to-6 converter changing
perl5 "C<pop;>" into "C<undef = pop;>" etc. Which ugliness is more
preferable? I like the idea of a "wasting" C<pop> or C<shift>
looking explicitly wasteful, at least some days. I am not taking an
assertive stance on this shaky sub-proposal.
=head2 3: For Functions In General
"C<stat>;", "C<length;>", and many others could use C<$_>. The
downside I see is that the parser gets bigger.
=head2 And So On:
Parts of this proposal may work nicely with
RFC 170: "Generalize =~ to a special-purpose assignment operator".
=head1 IMPLEMENTATION
...
=head1 REFERENCES
RFC 2: Request for new pragma: Implicit
RFC 51: Angle brackets should accept filenames and lists
RFC 56: Optional 2nd argument to pop() and shift()
RFC 139: Allow Calling Any Function With a Syntax Like s///
RFC 164: Replace =~, !_, m//, s///, and tr// with match(), subst(), and trade()
RFC 170: Generalize =~ to a special-purpose assignment operator
