> 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.
