Revised semantics for break within switch expression

Gavin Bierman gavin.bierman at oracle.com
Thu Apr 25 09:11:11 UTC 2019


Dear experts:

We are currently preparing a new JEP to make switch expressions a permanent feature. As stated on this list, we propose to replace the break with value form (e.g. break 42;) from the preview, with a new break-with statement (thus, break-with 42;), that is used to produce a value from an enclosing switch expression. 

This gives us an opportunity to reconsider some earlier design decisions. One I’d like your opinion on regards the control statements and which statements can handle them. Brian sent a summary table to this list a while back that is very useful:

              break-e  break  break-l  continue  return
switch-e      H	       X      X        X         X
switch-s      X        H      P        P         P
for/while/do  X        H      P        H         P
block         P        P      P        P         P
labeled       P        P      H*       P         P
lambda        X        X      X        X         H
method        X        X      X        X         H


where:

	+ X – not allowed
	+ P – let the parent handle it
	+ H – handle it and complete normally
	+ H* – handle it and complete normally if the labels match, otherwise P

The bit I’d like to reconsider is the break-e column. We initially decided that if a break-e occurred in a for/while/do or switch-statement, it would be super confusing if the break target was not this statement but an outer switch expression, even though it was a new form of break. So we proposed to ban it. For example:

    int i = switch (a) {
        default -> {
            switch (b) {
                case 0: break 0; // where does this transfer control?
            };
            break 1;
        }
    };

fails to compile:

    error: value break not supported in 'switch'
      case 0: break 0; // where does this transfer control?
                      

However, now we are proposing a completely new break-with statement, perhaps the potential for confusion is reduced? The break-with statement can only be used to produce a value for a switch expression. So there should not be a confusion if that switch expression contains a switch-statement or for/while/do statement. In other words, I would like to propose that we generalise the table to the following (changes in **-**):

              break-with  break  break-l  continue  return
switch-e      H           X      X        X         X
switch-s      **P**       H      P        P         P
for/while/do  **P**       H      P        H         P
block         P           P      P        P         P
labeled       P           P      H*       P         P
lambda        X           X      X        X         H
method        X           X      X        X         H


[It is useful to compare with the column for the return statement. This can return a value to the outer method/lambda regardless of any enclosing switch-statement or for/while/do statements.]

What do you think? 
Thanks,
Gavin


More information about the amber-spec-experts mailing list