An argument against this is that the user expects a list to be returned, not an array. Normally when a list is used on the right side of the expression, a scalar on the left side of the expression will be given the last value in the list, not the number of items in the list.

That's true when dealing with literal lists because that's how the comma operator works. Few builtin functions work this way. As far as the builtins go, there really is no standard way of relating both contexts. The perlfunc manpage says it nicely, "In general, they do what you want, unless you want consistency."

This argument at least indicates that wantarray is desirable, and that the other suggestion in this thread (returning the last item in the list) is preferable to returning the array itself.

There are many cases where wantarray is desirable. I even pointed out that Aristotle's case was probably one of them. I stand by my assertion, however, that most of the time returning the array makes more sense than using wantarray. For the record, I think that Zaxo's suggestion that the last element be returned is not very well thought out. For the general case, at least, it's a horrid idea. It's not exactly intuitive that a function would behave like a list literal and it wouldn't be very useful in most cases either. Besides, if you really want your function to act like a list literal, you could do it with a slice instead of wantarray; something like sub listify { @_[0..$#1] } for instance.

In terms of intuition, most people intuitively expect the following two expressions to be equivalent:

my($x) = foo(...);
[download]

And:

my $x = foo(...);
[download]

Sometimes the above is not the case, however, the times that this is not the case are usually the exception to the rule, and not the rule itself.

I disagree. The cases where those aren't the same are the rule. Consider

my ($x) = split//,"foo";          # $x eq 'f'
my $x   = split//,"foo";          # $x == 3

my ($x) = map $_, qw(foo bar);    # $x eq 'bar'
my $x   = map $_, qw(foo bar);    # $x == 2

my ($x) = localtime;              # seconds
my $x   = localtime;              # String like ctime(3)
[download]

The list could go on and on. So, though it's true people that are relatively new to perl might find the behavior you describe intuitive, it's also true that people with a modicum of perl experience learn not to expect it.

I, personally, often use "wantarray ? @array : $array[0]" as a return value, not only because I believe that this is the most intuitive behaviour, but also because in most cases, I consider this the most useful behaviour. Useful often directly equates to efficient from a programming perspective.

Again, I think this may be intuitive for someone that doesn't know perl but rather than that being the most useful behavior, I think it is simply hobbled. Here's an illustration:

sub foo { my @a = qw(foo bar); @a } 
sub bar { my @a = qw(foo bar); wantarray ? @a : $a[0] } 

my($p) = foo;    # $p eq 'foo'
my $q  = foo;    # $q == 2     (different information)
my($r) = bar;    # $r eq 'foo'
my $s  = bar;    # $s eq 'foo' (same information)
[download]

Doing it your way, both calls result in the same information. If one wants the number of items returned, one must call it in list context first and then retrieve the count in a separate operation. Where's the efficiency in that? Allowing the call in scalar context to provide that information in exactly the way we are used to getting it from actual array variables is the most useful behavior most of the time. It makes a good default. For those times when it makes more sense to provide other information in scalar context, wantarray is available.

-sauoq
"My two cents aren't worth a dime.";