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.