Deprecate ReturnStatements?

[Stewart Gordon]

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.