On Mar 2, 2018, at 8:12 AM, Brian Goetz <brian.go...@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