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 completion point. — John
