Disallowing break label (and continue label) inside an expression switch

[Remi Forax]

> 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.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.

yes ! 

> — John

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180302/8ab3ec38/attachment.html>