Which way "just works"?

At $work right now, you can find both of these:

    return wantarray ? @x : \@x;
[download]

    return wantarray ? @x : $x[0];
[download]

I wonder what will happen when one of those two programmers has to work on the other's code.

I didn't think context mattered

...or I didn't know I changed the context.

Imagine refactoring this:

my $dewdrop_description = get_droplet();
$dewdrop_description->{substance}       = 'water';
$dewdrop_description->{molecular_array} = get_moles( 'water' );
$dewdrop_description->{temperature}     = 37;
[download]

We want to eliminate the repetition. Make it like this:

my $dewdrop_description = {
    %{ get_droplet() },
    substance       => 'water',
    molecular_array => get_moles( 'water' ),
    temperature     => 37,
};
[download]

Nice, right? Yes, except now it's broken because at the end of get_moles() we have:

    return wantarray ? @moles : \@moles;
[download]

Our straight-forward refactoring has changed the context of get_moles() from scalar to list, and the result is that $dewdrop_description gets polluted with all manner of extra stuff. If you're lucky, get_moles() returns an even number of items, and you have warnings on, and you are told "Odd number of elements in anonymous hash". If you're not lucky, there's no warning, and an odd index element from get_moles() clobbers a key that get_droplet() returned.

Don't surprise me

I'm often looking at code already written for some example of how to use things. Given a "$scalar = x()", I expect that x() returns a scalar. I know very well that's not necessarily true and that context can have effects far beyond its source. Nevertheless, it generally does not occur to me that maybe this scalar-returning behavior is conditional.

A sub that returns more than one value can have unpredictable behavior in scalar context. What you get depends on whether the scalar context applies to an array or a list. If a sub returns a list, you can't just apply a scalar context to it and know what it will do without looking inside the sub to see what's to the right of return. In light of this, it almost seems merciful to use wantarray to lay down the law. A consistent use across code might actually clear some things up.

Still, I am not in favor of this.

Be consistent

Always return the same thing.

If your caller wants to stick your list in a scalar instead of an array, make it build the array reference itself.

If the list you return is so massive that copying it all is a burden, return an array reference. If the caller wants to copy it into an array anyway, it can dereference your return value and suffer the consequences.

On the defense

I've seen it suggested that every assignment from a sub call should be with a list context.

my ($scalar) = why();
[download]

This way, if it's giving you a scalar, you get it. If it's giving you a list, you get the first element. If it's giving you an array, you get the first element. It's about as consistent as you can get without looking into why().

I'm not quite to that point yet, but I can see where it's coming from.

A good use of wantarray

I think it's a good idea to use wantarray to check for void context. That can be used for run-time programming mistakes like calling an accessor in void context.

sub get_or_set {
    my $self = shift;

    if ( ! @_ && ! defined wantarray ) {
        die "accessor called in void context";
    }
    $self->{stuff} = shift @_ if @_;

    return $self->{stuff};
}
[download]

This will catch the case where you don't know you've passed in nothing.

my @x = ();        # but I thought it was qw( foo ) !
get_or_set( @x );  # set value
[download]

"Better" versions of wantarray

I'll note without comment that there are a couple of modules out there that do what wantarray does and more, if you're into that kind of thing.

• Contextual::Return—recommended by TheDamian in Perl Best Practices
• Want