Disallowing break label (and continue label) inside an expression switch
forax at univ-mlv.fr
Fri Mar 2 20:10:13 UTC 2018
> Envoyé: Vendredi 2 Mars 2018 20:45:52
> Objet: Re: Disallowing break label (and continue label) inside an expression
> On Mar 2, 2018, at 8:12 AM, Brian Goetz < [ mailto:brian.goetz at oracle.com |
> 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.
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.
> — John
More information about the amber-spec-observers