Deprecate ReturnStatements?
Stewart Gordon
smjg_1998 at yahoo.com
Thu Jan 6 14:29:54 PST 2011
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.
More information about the Digitalmars-d
mailing list