in reply to Re^2: why does push not default to $_? (simple)
in thread why does push not default to $_?

Or as more flexible approach "you can use "@_" and "$_" in prototypes to flag parameters which default to $_ if missing"
Is this a claim (that you can already do this) or a suggestion? If it's a claim, then note that _ is already a valid character in prototypes for a scalar argument defaulting to $_, as you want. If it's a suggestion, then I think that having a prototype syntax like @_ would be very confusing (besides being ambiguous, given that it conflicts with a currently valid, although useless, prototype), since @_ already has a quite different meaning.

By the way, notice that Params::Validate has a very rich defaults syntax for this sort of thing. In particular, you can do something like 

validate_pos 1, ( { default => $_ } ) x ( @_ - 1 )

[download]

UPDATE: Oops, that last snippet doesn't make any sense. Indeed, as I think about it further, what does it mean to have an array of values, all of which default to $_ if absent? I think it's best to stick with the case of allowing explicitly listed parameters to default: 

validate_pos 1, ( { default => $_ } ) x 57

[download]

Replies are listed 'Best First'.
Re^4: why does push not default to $_? (simple)
by LanX (Saint) on Dec 05, 2008 at 22:59 UTC
    it's a meditation!

    > that _ is already a valid character in prototypes for a scalar argument defaulting to $_, as you want.

    well, couldn't find it in the docs perlsub ... ups ...I was scanning the text und examining the examples and tables, but after a textsearch for "_" there is a somehow hidden phrase:

    As the last character of a prototype, or just before a semicolon, you can use _ in place of $ : if this argument is not provided, $_ will be used instead.

    wow, it's already implemented!

    So its possible to override CORE::push with sub push(\@_;@), which will default to $_ if the list is omitted!

    That means there is no technical reason that it's not already implemented this way, it's just Larry's decission.

    UPDATE Thats wrong, see following post...

    This thread is really instructive ... thanx! : )

    Cheers Rolf

[reply]
[d/l]
      I tried a prove of concept of overiding push, such that a missing second parameter defaults to $_. 
      use subs 'push';

my @a;
$_="x";

# push @a;  # Error: "Can't use an undefined value as an ARRAY referen
+ce ..."
print @a;

# Override!
sub push (\@_;@) {
  CORE::push( @{+shift},@_) ;
}

push @a;
print @a; # prints "x"

@b=("y","z");
push @a,@b;
print @a; # prints "2"

      [download]
      So it's possible to use push defaulting to $_, but a second Array to push will be forced into scalar context! 8(

      So the prototypesymbol _ doesn't work with parameterlists ...

      Cheers Rolf

[reply]
[d/l]
[select]
        I know that it doesn't have the elegance of what you're looking for, but why not just build in the default? 
        sub push (\@;@) {
    CORE::push ( @{+shift}, @_ ? @_ : $_ )
}

        [download]
        (Incidentally, this works for me, but is it guaranteed to do so? I seem to remember—but can't find—a discussion here a while back indicating that, while arguments are often evaluated left-to-right, they aren't guaranteed to be. Do we know that the shift will happen before we test the value of @_?)

        UPDATE: LanX points out an extremely good answer to “why not?”, namely, “Because it behaves like accessors that get/set based on whether they have/don't have an argument, and passing an empty list leads to surprises.”

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom