"Final expression is return value" is an easy and basic meme for Perl, going all the way back to Perl 1. The unnecessary use of return deserves, not recommendation, but quiet disdain.

Adding an explicit return is just like adding "unneeded" parentheses: a way of expressing things more explicitly (and maybe more clearly) if the author wants. Let people write with their own style; I see no need for disdain or for fear that explicit returns will be mandatory in the future. I agree that freedom should remain one of the attractive features of Perl; people who want to have only one way of doing things have other languages to choose from.

I dunno, I'm not a newbie and I like seeing it. Its strange to write return() in some places but not others. I suppose I could think of it like writing scalar() some places but I haven't.

When you think of "return" as "return from this subroutine early", it becomes very clear where you need it: everywhere that you want the subroutine to abort before it would have otherwise. And, by the way, you can also specify the "last expression evaluated" as a convenience after the return. {grin}

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

I think your disdain may be misplaced. Whenever writing perl code it is always important to consider the audience for the code you are writing; the compiler is one member (and a very important member) of that audience, but so are you as the author, and often so are other people that may need to maintain it or desire to understand it in the future.

I frequently use return at the end of a function or method. I frequently omit return at the end of a function or method. Which I choose to do in any particular situation is primarily down to whether I feel the return adds clarity.

It is rare that I write code that is so resource-critical an extra opcode would make a difference; when I do, of course, I don't use return.

Hugo

Actually, this "Final expression is return value" is IMO a mistake of perl. The final expression should only mean a return value iff it's not followed by a semicolon.

That can only be done in free-form languages (where a newline doesn't mean end of the command, like perl or C but unlike awk or ruby or python). That way, you wouldn't have to add return (or undef) statements just to make a function void.

Yes, there's already one such language: Mathematica treats semicolon as an operator that just returns its second argument (like scalar comma in perl, comma operator in C, begin in scheme). It's a function like any operator in Mathematica (well, any but one, @@@), it's called CompoundExpression. When it is used without second argument (that is, when you just put a semicolon after an expression) the second argument is implicitly Null.

Update: fixed a typo.

The final expression should only mean a return value iff it's not followed by a semicolon

That's a joke, right? (I say hopefully...)

If not, what happens when you use a void-return function in non-void context; a fatal error? silent promotion to undef/empty list? Camels fly out your nose?

Not to be critical, that's a really lousy idea. If you want to forbid attempts to use a return value, say carp "blah" if defined wantarray;