> Envoyé: Vendredi 2 Mars 2018 20:45:52 > Objet: Re: Disallowing break label (and continue label) inside an expression > switch
> On Mar 2, 2018, at 8:12 AM, Brian Goetz < [ mailto:brian.go...@oracle.com | > 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. I'm glad we all agree here. > (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. yes ! > — John Rémi
