There's some convenience you can provide: You can return an array reference in scalar context, and the array itself in list context:

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

The the caller can decide which version she wants.

Perl Best Practices is a little thin in this area. In (very brief) synopsis Damian suggests that you should "return what the caller expects".

In this case that may be return a list in list context and return an array reference in scalar context. You can achieve that by using wantarray:

sub genMeggaArray {
    my @array;
    
    ...
    
    return wantarray ? @array : \@array;
}
[download]

Another way to help avoid the confusion is to, as mentioned already, return the ref in scalar context and the array in list context consistently across all your data-returning methods or subs and to document the fact that it is always that way across the whole API as part of your API documentation.

I could imagine that you do pretty much the same things with all the arrays you return from your various subs (checking their sizes, iterating over them etc).

So why not wrap your arrays in an object that provides nice convenience methods, iterators etc do make life easy for the client code?

In that way you ALWAYS return the same entity (an object - contextual returns are nice but can be confusing to some people) regardless of the list-size (with the memory consumtion of a returned reference), so no special cases and you could build an interface like this:

my $ret = &my_sub(@args);   # returns an object that wraps a list

if(! $ret->isEmtpy ) {
 $ret->each( sub { print $_ } );
}
[download]

Just an idea...

If the array actually represents a vector or matrix, then there's already a good library for it: PDL.

If not, chances are that there's already a good library for it on CPAN anyway ;-)

my $ret = &my_sub(@args);

In general there's no need to add the & in front of sub calls. On the contrary it has some effects that aren't desirable most of the time, like disabling prototype checking.

And I thought prototype checking was undesirable :-)

I just added the "&" for clarity - and I sometimes use it myself in some one-off hacks where I call a sub before I define it (just to keep the parser happy).

Apart from prototype checking what else are the differences between

&foo(@args);
[download]

and

foo(@args);
[download]

?