www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Deprecate ReturnStatements?

reply "Manfred_Nowak" <svv1999 hotmail.com> writes:
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. 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(){}' and `(cast(void) 1).return;' whitin `void f(){}' to make returning a constant to void as legal as using a constant as an expression: `cast(void) 1;'. -manfred
Jan 02 2011
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Manfred Nowak:

 Walters remark suggests that the dysmorphism between returnStatement and 
 expressionStatement is based on arbitrariness:
 ...
 To make this homomorphic it might be adequate to view returning as an 
 attribute of an expressionStatement:
To better contextualize Manfred notes I suggest this post of mine: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=23652 Bye, bearophile
Jan 02 2011
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jan 06 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/6/11 4:29 PM, Stewart Gordon wrote:
 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.
Guys, this is getting really bizarre. We now have syntax proposals for fixing... what problem? Walter, please drop that feature and let's move on. Again, you can take my word that such a feature offers nothing to generic and generative programming. Andrei
Jan 06 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Walter, please drop that feature and let's move 
 on. Again, you can take my word that such a feature offers nothing to 
 generic and generative programming.
Thank you Andrei :-) Bye, bearophile
Jan 06 2011