RFC 215 (v2) More defaulting to $_

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