Don wrote:
In the docs for "return statement" in statement.html it says:
---
ReturnStatement:
return;
return Expression ;
Expression is allowed even if the function specifies a void return type.
The Expression will be evaluated, but nothing will be returned.
----
This makes sense for things we definitely want to allow, such as:
void foo() { return bar(); }
where bar() is another void function. But as currently implemented, it
also allows bug-prone code. Here's an example from std.utf in Phobos2:
// BUG: should return size_t, not void!
void encode(wchar[2] buf, dchar c){
if (c <= 0xFFFF)
return 1;
return 2;
}
I think that instead, inside a void function, return expression; should
be the same as: { expression; return; }, ie, like any other expression
statement, it should be required to have side-effects. I found while
patching the ICE bug 3344 that this is happening because the expression
never gets the semantic pass run on it.
In DMD, in statement.c.
Statement *ReturnStatement::semantic(Scope *sc)
=====
/* Replace:
* return exp;
* with:
* exp; return;
*/
Statement *s = new ExpStatement(loc, exp);
+ s->semantic(sc);
=====
After making this change, it showed up that bug in Phobos.
I'm not sure if the current behaviour is intended, or is a bug. It
certainly looks unhelpful, unexpected, and bug-prone to me. As well as
the one-line compiler patch, I suggest the following change in the spec:
-The Expression will be evaluated, but nothing will be returned.
+The Expression will be evaluated as an ExpressionStatement, but nothing
will be returned.
Or is there something desirable about the existing behaviour which I
have missed?
I agree with your assessment.
Andrei
