note sauoq <p>Expectations should be defined by the language, not the programmer. Therefore, I think we should standardize on... well, nothing. Because Perl doesn't. I do, however, believe there is a best practice: unless you have a very good reason, it is best to sidestep the issue entirely and let Perl provide behavior that is already familiar to the programmer.</p> <p>It is easy to imagine a function where it makes the most sense to return a reference to an array in scalar context. Likewise, it is easy to imagine one where it makes the most sense to return a formatted string. Neither would make sense as a default though. They are special cases.</p> <p>In fact, the only time you should be mucking around with the return value in different contexts <em>is when you have a special case</em>. (And it just so happens that many, if not most, of Perl's builtins are sensibly treated as special cases.)</p> <p>The <strong>right</strong> "default" behavior, in my opinion, is to <code>return @ret;</code> and let the programmer using your function sort it out. Document that your function returns an array and be done with it. Perl does a fine job of defining expectations for arrays, and your function can rely on those... <code> my $nelts = @array; # Number of elements. my ($first) = @array; # First element. my @whole = @array; # Whole thing. sub some_func { return @array } my $nelts = some_func(); # Number of elements. my ($first) = some_func(); # First element. my @whole = some_func(); # Whole thing. </code> That's about as consistent as it gets in Perl. It'll serve you well too, should you need to globally replace an array with a function call or vice-versa.</p> <p>I think that returning a list literal (such as you create with the slice <code>@ret[0 .. $#ret]</code> in your example) is sorta-semi-okay as an alternative, but probably not nearly as useful. It also isn't very common practice and should probably be much more carefully documented when used. Still, I suppose Perl provides the right expectations insofar as <code>$x = qw( a b c );</code> and <code>sub f { qw(a b c) }; $x = f();</code> both set <tt>$x</tt> equal to <tt>'c'</tt>.</p> <p>Out of all of your examples, the one that makes me cringe is your "something completely different" example. Why go to the trouble ensuring <code>my $i = foo();</code> is equivalent to <code>my ($i) = foo();</code> when most perl programmers have already gone to the trouble to learn that they probably aren't? It hardly seems worth the obfuscation. I expect most, if they ran across that function, would spend much longer trying to figure out exactly why you did it that way than they ever would working out a bug caused by calling it in scalar context. I include myself in that.</p> <div class="pmsig"><div class="pmsig-182681"> <pre> -sauoq "My two cents aren't worth a dime."; </pre> </div></div> 311537 311537