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