Language Change Specification for Conditional Return Statement

LCS Number: LCS-2016-094
Version: 2 {25-Jan-2017}
1 {23-Dec-2016}
Date: 25-Jan-2017
Status: Voting
Author: Jim Lewis
Email: Main.JimLewis
Source Doc: Conditional Return Statement
Summary: Conditional Return Statement

Voting Results: Cast your votes here

Yes:

  1. Ryan Hinton - 2016-12-27 - ver 1
  2. Martin Zabel - 2017-01-26 - ver 2
  3. Patrick Lehmann - 2017-01-26 - ver 2
  4. Lieven Lemiengre - 2017-01-27 - ver 2
  5. Jim Lewis - 2017-03-13 ver 2 if 36a fails
  6. Rob Gaddi - 2017-02-27 - ver 2 if 36a fails

No:

  1. Kevin Jennings - 2017-2-8 - Ver 2. Does not meet proposal's use case "return (<expression 1>) when <condition 1> else <expression 2>) when <condition 2> else...
  2. Rob Gaddi - 2017-02-27 - ver 2 if 36a passes
  3. Thomas Preusser - 2016-12-28 - ver 2 - following Kevin and considering Rob's comment, suggest LCS094a
  4. Jim Lewis - 2017-03-13 ver 2 if 36a passes

Abstain:

  1. Brent Hayhoe - 2017-02-16 Version 2 - Abstain due to lack of personal time for review.
  2. Martin Thompson- 2017-02-17 Version 2 - Not sure I'd use this

Style Notes

Changes are shown in red font. Deletions are crossed out. Editing notes in green font.

Reviewing Notes

See also alternative LCS094a.

Details of Language Change

Section 10.13 Return statement

production for return statement on page 168

return_statement ::=
[ label : ] return [ expression ] [ when condition ] ;

paragraph before notes in section 10.13 on page 168

For the execution of a return statement, the expression (if any) is first evaluated and converted to the result subtype. The execution of the return statement is thereby completed if the conversion succeeds; so also is the execution of the enclosing subprogram. An error occurs at the place of the return statement if the conversion fails.

For the execution of a return statement, the condition, if present, is first evaluated. If there is a condition, and it is FALSE, the return statement completes and execution of the subprogram resumes. If the condition is TRUE or if there is no condition, then the expression (if any) is evaluated and converted to the result subtype. If the conversion fails, an error occurs at the place of the return statement. If the conversion succeeds, the return statement completes and the enclosing subprogram completes.



Comments

The execution of the return statement also completes when the condition is false, but then the execution of the enclosing subprogram does not complete.

-- Martin Zabel - 2017-01-09

@MZ Thanks Martin. I rewrote the paragraph to better address your concerns.

-- Jim Lewis - 2017-01-26

@TODO Consider how this collides with 36a - conditional expressions @TODO In proposal explain that it is not about the value returned, but whether to return a value or not retrun.

-- Jim Lewis - 2017-02-09

Is it ok to require return (conditional_expression) when condition ; and return (conditional_expression) ;

-- Jim Lewis - 2017-02-09

If approve 36a, can return conditional_expression and if the conditional expression return unaffected then there is no return.

-- Jim Lewis - 2017-02-09

KJ: Does not meet proposal's use case "return (<expression 1>) when <condition 1> else <expression 2>) when <condition 2> else..."

PL: Yes the proposal got extended, but the original use case is a language regularization to equalize all 3 control flow statements: next, exit and return. Next and exit can be used with an expression, but return not. The added use case of multiple possible return values can be achieved with LCS 036a.

-- Patrick Lehmann - 2017-02-12

@KJ: With the revised 36a, conditional return allows

return (<expression 1>) when <condition 1> else <expression 2>) when <condition 2> ;

Since expression expands to (conditional_expression)

-- Jim Lewis - 2017-02-21

Discussed in Feb 23 meeting.

Must be expression and not conditional_expression.

Should not replace entire RHS conditional_or_unaffected_expression as unaffected is not a good way to express do not return.

-- Jim Lewis - 2017-02-23

@KJ, in conjunction with LCS_2016_36a, this is allowed return (A when cond1 else B when cond2 else C) when RTNCOND ;

-- Jim Lewis - 2017-02-23

Yes, but as written this doesn't allow

return <expression 1> when <condition 1> else <expression 2> when <condition 2> ;

to mean that condition 1 has priority, then condition 2, and otherwise fall through.

-- Rob Gaddi - 2017-02-23

JL: Discussed in Feb 23 meeting. Must be expression and not conditional_expression.

KJ: I'm not seeing then how one can return more than one expression. LCS 36a defines conditional_expression ::= expression { when condition else expression }. This LCS defines return [ expression ] [ when condition ]. So how does one get the 'else' branch for the return?

-- Kevin Jennings - 2017-02-23

@KJ: Use parenthesis:

return (a when c else b) when done;

-- Thomas Preusser - 2017-02-23

@KJ: The use case "return (<expression 1>) when <condition 1> else <expression 2>) when <condition 2> else..." could also be accomplished by:

return (<expression 1>) when <condition 1>;
return (<expression 2>) when <condition 2>;
...

And this is also much easier to read than putting it into one line.

-- Martin Zabel - 2017-02-24

Martin, I'd say that's only true for complex cases. The real use model to me is simple cases, the ones where you don't tie yourself in linguisitic knots in the writing of them. I'd sure like to be able to say both.

return A when (SEL = '1') else B;

and

return '0' when not ANDTERM;

and not have strange syntactic differences between them, given that I don't have them when I use a conditional assignment. I just want a nice, clean, high symmetry language.

-- Rob Gaddi - 2017-02-27

To continue rambling on about what I was going on about on during the meeting on the 23rd...

Combined with 36a, my preferred evolution of this is:

  return_statement ::= [ label : ] return [ conditional_expression_or_unaffected ] ;

where a resultant value of unaffected means that you don't return, and instead continue with execution. Yes, you could use that to go around writing horrible things with explicit use of unaffected rather than have unaffected only come through as the implicit catch-all else clause. But people could do a lot of horrific things. What it really gives you is exactly what I said in my comment above; a unified syntax for anywhere you're using when to create a conditional thingy, regardless of what type of thingy you want to do conditionally.

It would mean that:

  1. return '1' when A else '0' when B;
  2. return ('1' when A else '0') when B;

have different meanings but both are valid. I don't think either scans badly or makes its intent unclear. If we demand the trailing when be a part of an entirely separate language chunk, then 1) has to be written return ('1' when A else '0') when (A or B); which buries the intent.

-- Rob Gaddi - 2017-02-27

@Rob: See LCS094a for a proposal that provides what you want.

-- Thomas Preusser - 2017-02-27

Topic revision: r29 - 2020-02-17 - 15:34:42 - JimLewis
 
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback