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;
| [reply]
[d/l] |
No. Let me elaborate.
My proposal is that when there's a semicolon after the last statement, the subroutine (either anonymous or not) should return undef or empt list depending on the context (unless you exited it with a return statement), else ti would return the result of the last statement.
This would be better both in the case of a void and a non-void subroutine. If you want to create a void subroutine,
you just omit the semicolon after the last statement.
This causes no ambignuity, as the commands that
usually don't need to end in a semicolon
(if, while, for etc) are void anyway.
In perl, if you have a subroutine whose last statement is an expression, you now have to add an additional return or () to amke the function void.
Why would one want to make a function void? If a function returns a value, someone might use it accidentally and don't easily see the error; if the function is void, the undefined return value in scalar context is likely to give an undef warning. Worse still, someone may find that a function that you intended to be void returns a particular kind of information. Later when you change the function, his code just fails to work, as you don't care what the sub returned as it's meant to be void.
In case of non-void subs, you just had to take care not to add a semicolon; you already often do that when writing short blocks for map etc, don't you?
This is not entirely inlogical, you can also think of it like this: tha last statement must never end in a semicolon. If there's a semicolon there, then an empty statement is following it, which should be defined to have a result of () (it now doesn't as sub a {2;;;} a returns 2 despite of the apparent empty statements.
Of course, this is just a speculation, too late to change now, it would yield to a lot of incompatibility. Perl should remain as is.
Update: I was wrong. As ysth pointed in his reply,
the "last expression" rule goes inside
if and while (and strangely it seems to return the evaluated
condition of a prefix if statement without
an else branch, and also with a postfix
if,unless,while conditions but not the others).
The semicolon rule I've sketched would not fit well with this behaiviour.
| [reply]
[d/l]
[select] |
commands that usually don't need to end in a semicolon (if, while, for etc) are void anyway
for is, everything else follows the "last expression is the return value" rule.
| [reply] |