Call for bikeshed -- break replacement in expression switch

[Brian Goetz]

> So in colon-form switch (whether statement or expression) you are responsible for your own control flow, and in arrow-form switch (whether statement or expression) you are not. "break" is synonymous in users' minds with that control flow they don't want to have to do. So in theory it's arrow-form that should make the concept of "breaking" obsolete. Unfortunately, that doesn't seem like the distinction we'll making; do I have the following right?

In colon-form, you are always responsible for your control flow.
In arrow-form, you are generally not, except that if you have a block on the RHS of the arrow, you are responsible for control flow _out of the block_.  

In:

    y = switch (x) {
        case 1 -> { 
            foo();
            yield 3;
        }
    };

there is a pleasant ambiguity as to whether the “yield 3” is yielding a value to the _block_, in which case the switch just completes normally, or whether it is yielding the value to the _switch case_.  And it doesn’t really matter, so whichever intuition users are attracted to, is fine.  
> A colon-form case in a switch statement stays absolutely the same as always - keep `break`ing
> An arrow-form case in a switch statement usually doesn't need to `break`... but can, just as an early-out from a block, right?
> A colon-form case in a switch expression cannot `break` at all; it either yields, throws, or falls through
> An arrow-form case in a switch expression: cannot `break` or fall through; must be a single expression, or it must always `__yield` or throw

Right.  There are several rules interacting here:

 - An expression must either yield a value or throw; control statements like break, continue, or return is not allowed in a “structured expression.”
 - You break out of a switch statement; you yield values from a switch expression
 - In arrow form, neither break/yield is needed if the RHS is not a block
 - In arrow form, break/yield/throw *is* needed if the RHS is a block

> So using break or not isn't about whether you are doing your own control flow or not. So it's not a nice conceptual clean break that way, but in practice we think most switches will be all #1 or all #4, do we not?

I would expect 1/4 to be the most common, followed by 2, with 3 bringing up the rear.  

> Anyway, I don't dislike yield even though I know it has other connotations. I think it communicates "I am done and I give forth this value", and what happens from there can be context-dependent and that seems fine....
> 

Yep.  And that context dependency is:

 - Yield yields to the immediately enclosing structured expression; if there is none, it is an error
 - Unlabeled break/continue breaks to the immediately enclosing “breaky” statement, if there is none, its an error, but cannot “break through” a structured expression.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190513/bc356a4b/attachment.html>