Language Change Specification for Conditional Return Statement

Annex C - Syntax Summary

edit 94a.7

return_statement ::=
[ label : ] return [ expression ] ;
  value_return_statement | plain_return_statement [§10.13]

plain_return_statement ::=
  [ label : ] return [ when condition ] ; [§10.13]

value_return_statement ::=
  [ label : ] return conditional_or_unaffected_expression ; [§10.13]

Comments

This LCS should name it's dependencies to the LCS 036 series. It misses changes for annex C. It also requests too many ";".

Why does this LCS generate two different return statements for functions and procedures?

-- Patrick Lehmann - 2017-02-27

PL: This LCS should name it's dependencies to the LCS 036 series.

It does - in the header. Excuse the misnomer I had used for the label before.

PL: It misses changes for annex C.

Added. They are missing in LCS 094 as well.

PL: It also requests too many ";".

Fixed.

PL: Why does this LCS generate two different return statements for functions and procedures?

Because a conditional_or_unaffected_expression cannot reduce to a when condition. Alternate suggestions to put this into a shorter grammar with a concise semantic specification are welcome.

-- Thomas Preusser - 2017-02-27

I'm against the different elaboration behaviors of functions vs. procedures and vs. other conditional flow control statements.

-- Patrick Lehmann - 2017-02-28

I do not see where you find a "different elaboration behavior". In a way, a return statement in a function does, indeed, differ from all other control flow statements: it needs a value to work with.

Anyhow, you are welcome to be constructive, look at Rob's comments on LCS 094 and come up with a solution that you like. You will have my vote immediately if you manage to boil this down to a more concise LCS - although this one is not very long either.

-- Thomas Preusser - 2017-02-28

The current conditional control flow statements exit and next have already an optional condition. The purpose of the proposal is a language regularization. So the third control flow statement return shall get a condition too. This is achieved by LCS 094.

The difference between LCS 094 and 094a is the order of elaboration.

*LCS 094*

1. the condition is evaluated
2. the statement is executed, if the condition results in a BOOLEAN value TRUE

Thus we can say elaboration happens from right to left. This is also true for the next when ... and exit when ... statements.

*LCS 094a:*

1. conditions are evaluated from left to right.
2. the first condition resulting in a BOOLEAN value of TRUE wins
3. the statement is executed, if not unaffected

I dislike that the return when ... statement gets another order of evaluation then then next and exit statements.

I don't need to present a solution, because there already one: 036a + 094, but not 094a

-- Patrick Lehmann - 2017-03-11

This LCS need to change more paragraphs in 10.13. because it exchanges expression by conditional_or_unaffected_expression. Several text positions reference expression.

-- Patrick Lehmann - 2017-03-11

PL: Thus we can say elaboration happens from right to left. This is also true for the next when ... and exit when ... statements.

TBP: There is also no unnatural reading of the conditional return as suggested by this LCS. It can only be effective if a condition to the right of the keyword evaluates to true. Allowing (not demanding!) the explicit use of unaffected in the decision process simplifies hierarchical decision that do not have the unaffected case in a natural end position. This cannot be achieved by LCS 036a + 094. They also require extra parentheses needlessly for an internal value selection.

PL: This LCS need to change more paragraphs in 10.13. because it exchanges expression by conditional_or_unaffected_expression. Several text positions reference expression.

TBP: While the term "expression" has never been ambiguous in the context of 10.13, I followed up on your comment and reworded the section altogether.

-- Thomas Preusser - 2017-03-13