Most of the time I wouldn't be tempted to write functions that operate on $_ if given no arguments. trim($_) is just not a big hardship compared to trim() (although I do use implicit $_ in some cases, I usually don't with chomp(), for example).

If I had a function that used $_ when given no arguments, then I'd likely not support taking a list of arguments (because of the ambiguity you noticed). Though, if you aren't likely to run into a relatively old version of Perl, then there is a somewhat ugly way around the ambiguity problem that I'm reluctant to mention because somebody would probably use it:

Interesting, I never thought of that method to figure out the arguments. But you're right, forcing the 1st argument into a reference breaks too many usual idioms (such as trim(<STDIN>) as you mentioned).

I wish that "@_" was undef when a function is called with no arguments (as opposed to called with an empty array). Or, that there was some other way to detect no arguments without forcing the 1st argument into a reference.

I appreciate the "spoiler". I'll add it to my perl KB (even if I never use it).

- Wyrd

I wish / ... / that there was some other way to detect no arguments without forcing the 1st argument into a reference.

There is, kind of.

sub foo {
    (caller(0))[4]
        or return foo($_);

    ...;
}
[download]

This will make $_[0] become aliased with $_ if foo was called with &foo and without the parenthesis. Personally I wouldn't use this. It will only lead to trouble.

lodin

I thought about the undef vs. empty thing myself. It'd be rare, but it might break things for some people.

Then I thought about $#_, which turns out to be -1 for both cases. I imagine changing it to, say, -2 for the empty list wouldn't break much, but there's always that chance. It also seems a little too magical and would definitely be a FAQ if it was done that way.

I had pretty much the same thoughts about $_[-1]. Making it special for this case could be handy, but it's probably a bad idea.

It'd be really nice if there was a variable or a built-in one could check that says whether there were any arguments to a function or not without enumerating them. Of course, a new built-in could break programs that have name conflicts with the new built-in.

sub foo {
    if ( has_args ) {
        foreach ( @_ ) {
            # ...
        }
    } else {
        # ..., but with $_
    }
}
[download]

Even an additional field on the end of caller could work I suppose, but (caller(0))[4] seems unsuitable at present. Perhaps if it returned 0 for &foo, 1 for foo(...), and zero-but-true for foo() it would be handy here. The nice advantage to adding to the end of an array that already gets returned is that it only breaks where one is taking [-1] as an element from the array... which is the same issue I guess as above.

I like the zero/one/zero-but-true option for the fact that currently people probably only test for truth and not for equality to one, so making a special case such as empty args with parentheses or an empty list (pretty much the same for this scenario) probably wouldn't break anything. Of course, someone somewhere would get paged into work for a broken production system if just to prove me wrong.

sub trim
{
    my @args = ( @_ ) ? @_ : $_;
    for ( @args ) {
        s/\A\s+//;
        s/\s+\z//;
    }
    return wantarray ? @args : $args[0];
}
[download]

Update -- test suite:

#!/usr/bin/perl

use strict;

sub trim
{
    my @args = ( @_ ) ? @_ : $_;
    for ( @args ) {
        s/\A\s+//;
        s/\s+\z//;
    }
    return wantarray ? @args : $args[0];
}

$_ = " test  ";
print "test 1: ==" . trim . "==$_==\n";

$_ = " 1234  ";
my @b = ();
trim( @b );
print "test 2: ==". $_ . "==@b==\n";

my @c = ( "  a ", " b  ", " c " );
my $d = join "", trim( @c );
print "test 3: ==". $_ . "==" . $d . "==@c==\n";

__OUTPUT__
test 1: ==test== test  ==
test 2: == 1234  ====
test 3: == 1234  ==abc==  a   b    c ==
[download]

Having updated "test 1" to print out both the return value of trim and $_, I see that $_ is never modified, which I gather is not what you want. Sorry -- I get your point now, and I don't have an answer.

Test 1 is fine. $_ shouldn't be modified in that case. (Not void context.)

Test 2 is the one that fails. It doesn't print == 1234  ==1234== as it should.

sub trim {
  my (@out) = @_;
  
  foreach (@out) {
    s/^\s+//;
    s/\s+$//;
  }
  return wantarray ? @out : $out[0];
}
[download]

No, the "shortcut" idiom modifies its arguments in place if called in void context. I only want to disconnect aliasing if the function is called in a non-void context.

That way the function will return value(s) when asked or operate on it's arguments in place when called appropriately. Eg:

@strs = ( " a string ", " b string ");
$s = " my string ";
$a = trim($s);    # $a gets the trimmed version of $s
@b = trim(@strs); # @b gets trimmed versions of all strings in @strs
trim($s);         # trim $s in-place
trim(@strs);      # trim all @str in-place
[download]

- Wyrd

How does this code differentiate between being call with no args and being called with an empty list?

It doesn't. I misunderstood your question.

I'd be inclined not to permit this if only to maintain the law of least surprise. If it needs to operate on $_ sometimes there are ways to test for that and make it happen.