Well, if works in that it returns the result of the last expression evaluated. It seems that's what looping constructs should do too. Wouldn't it make sense for this sub x { $_ for 10 } to return 10?
Not really. If you're asking my opinion I'd say it should be an error if the sub is called in anything other than a void context. Note the following are also compilation errors...
my $what = (if(1){print "true"}else{print "false"});
sub foo
{
return (for (1..3) { print $_ });
}
You're not arguing that they shouldn't be, are you?
| [reply] [Watch: Dir/Any] [d/l] |
You're not arguing that they shouldn't be, are you?
No, I'm certainly not. I'm perfectly happy that those are errors. I don't know if it follows that sub x {$_ for 10} should be an error but I can see the argument for it. I see usefulness on both sides. Causing an error would be useful in preventing some god awful code while returning the result of the last expression evaluated would be useful in some god awful code. Usually, when there is a choice like that, Perl supports the latter but prints a warning under -w ... :-)
-sauoq
"My two cents aren't worth a dime.";
| [reply] [Watch: Dir/Any] [d/l] |
Usually, when there is a choice like that, Perl supports the latter but prints a warning under -w
I'll second that notion. The interpreter should be fixed to implement this idea and the documentation should be changed to something like...
If the last thing (Note 1) in a subroutine is an expression, then the return value of the subroutine is the value of that expression. Otherwise if the last thing in a subroutine is a statement (if, for, while, etc.) and the subroutine is called in non-void context, then issue a warning. Alternatively, a return statement may be used to exit the subroutine, optionally specifying the returned value, which will be evaluated in the appropriate context (list, scalar, or void) depending on the context of the subroutine call...
Note 1: We should another word besides "thing" but I'm not sure what that is.
| [reply] [Watch: Dir/Any] |