On 02/01/2011 13:01, Manfred_Nowak wrote:
Walter Bright wrote:
writing generic code so that the same code can be generated for void
and non-void return values.
http://d.puremagic.com/issues/show_bug.cgi?id=5399 (cited 01/02/11)
The docs include:
| Expressions that have no effect, like (x + x), are illegal in
| expression statements. If such an expression is needed, casting it to
| void will make it legal.
http://www.digitalmars.com/d/2.0/statement.html#ExpressionStatement
| If the Expression has no side effects, and the return type is void,
| then it is illegal.
http://www.digitalmars.com/d/2.0/statement.html#ReturnStatement
( both cited 01/02/11)
Walters remark suggests that the dysmorphism between returnStatement and
expressionStatement is based on arbitrariness: generating an expression
by generic code must still take into account, whether the genrated
expression will be used for an expressionStatement or a returnStatement.
This is because casting to void will not legalize an expression without
side effects for a returnStatement, but for an expressionStatement only.
Then why not fix ReturnStatement so that
return cast(void) Expression ;
is always legal in a void-returning function?
Perhaps the way to do it is to define that the semantic analyser always
deems cast(void) Expression to have a side effect.
To make this homomorphic it might be adequate to view returning as an
attribute of an expressionStatement:
`(void).return;' instead of `return;' whithin `void f(){}'
`(1).return;' instead of `return 1;' whithin `int f(){}'
<snip>
I don't really like this - it seems unnatural. return is a control flow
statement. Properties of objects, by their nature, don't control the
flow of the calling function (throwing exceptions aside).
Stewart.
