Disallowing break label (and continue label) inside an expression switch
john.r.rose at oracle.com
Fri Mar 2 19:45:52 UTC 2018
On Mar 2, 2018, at 8:12 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> Do we disallow the "break TOP" and return in the inner switch?
> IOW, does the expression form a barrier through which control
> can only pass via break or exceptions?
IIRC last time we talked about this that was the consensus.
It's consistent with what Kevin just wrote also, about constraining
the result of a switch-expr.
We currently don't have any expressions which can branch,
just return normally or throw. Let's keep it that way.
(Remember we had an option for lambdas to branch
outside the lambda expression, and we decisively shut
it down for various reasons.)
We *do* have expressions which can *internally branch*
without completing. Those are lambdas. Switch expressions
should also be able to have arbitrary control flow inside
(if the coder decides). But that "barrier" idea expresses
the key constraint: That the branch labels used inside
the switch are operationally disjoint from those outside.
(Separately, as a syntax constraint, labels enclosing
the same bit of syntax should be distinct. But that
doesn't mean an outer label is ever reachable from
inner control flow. Trying to reach across the barrier
must be an error.)
If someone wants to write code like Remi's puzzlers,
fine, but they have to refactor to a statement-switch,
and assign the result to a temp, like today. Statements
can branch to locations other than their standard
More information about the amber-spec-observers