then it should always return a "list", even in scalar context, i.e. if called in scalar context return the last value in its return expression.
I don't know how to not interpret that as "being a 'list' means that it will return the last value in a scalar context". And I don't think the scare quotes make that more clear or less misleading. And using that with "always return" makes it more confusing to me.
As for what is least surprising, I find that it depends completely on what the function does. Having scalar( caller() ) be the same as ( caller )[-1] would make no sense and so would certainly be surprising. Returning the first item, returning a reference to an array, or returning a string that includes all of the items are three behaviors that I often find appropriate. Returning the last item is not something I choose often.
| [reply] [d/l] [select] |
Okay, after much contemplation, I've come up with a way to not interpret it that way. It requires two strange interpretation of two words.
I started with jdporter's reply above which implies that "'list'" (with scare quotes) means some specific thing and this thing returns its last item when used in a scalar context. So a good guess would be "list literal" a.k.a. "parens around comma operators". I certainly didn't jump to that interpretation because taking a rather vague term ("list") and adding scare quotes doesn't make me think it is meant to be something more specific, much less lead me to which of the many more specific things it could be. But even trying to use that interpretation just leads to another problem. You can't "return" a list literal.
The verb "return" is all about values, not expressions. I can use a hash (expression) as the argument to the return keyword but I can't return a hash. The return keyword (or "function", if you prefer) takes an expression and then returns a value ("... or list of scalar values" if you don't consider "value" to encompass "list") that results from that expression. It does not return the expression. return %hash; doesn't return a hash; it returns a list of alternating keys and values. return foo(); doesn't return a function call. And return( $a, $b, $c ); doesn't "return a list literal". So "return a list" (w/ or w/o scare quotes) means that "list" means some sort of value, not a type of expression. And "list value" is a pretty clear concept in Perl, as it happens, so it is hard to not interpret "list" as "list value" in such a sentence.
Now, I'm not saying that this is actually what jdporter meant, since I don't know. I hope he'll provide that at some point himself. But it did lead me to ponder further that I rarely use list literals as return expressions and, when I do, that usually means that the last value is not the appropriate return value in a scalar context.
I find that using a list literal as a return expression most often means that one has a fixed collection of values that aren't tightly related such as all being the same type of information (else they'd likely be in an array). And when returning such a varied list from a function, most often the most important, more interesting, or most basic item of information is the one you return as the first item of the list. And, in a scalar context, that is also the item that you are most likely to return. So, using a list literal with return usually means I want to return the first item in a scalar context or I want to return a string that combines the items. Note that either of those cases means that I need to use wantarray.
| [reply] [d/l] [select] |