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

On Mar 28, 2018, at 4:13 PM, Dan Smith wrote: > >> On Mar 23, 2018, at 1:41 PM, Brian Goetz > > wrote: >> >> I prefer the simplicity that "all expressions either complete normally or >> complete abruptly with cause exception." > > Just want to emphasize that this

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

> On Mar 23, 2018, at 1:41 PM, Brian Goetz wrote: > > I prefer the simplicity that "all expressions either complete normally or > complete abruptly with cause exception." Just want to emphasize that this is a really important property of the language, and of what we mean when we call some thin

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

> On 23 Mar 2018, at 20:51, Guy Steele wrote: > > > String s = switch (e) { > case 0 -> break “foofoo”; > case 1: > if (p == 0) break x; > else { String z = hairy(x); break z+z; } > case 2 -> “barbar”; > }; > > Now I decide that case 1 has three

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

Stepping back, I think there's two ways to look at this:  - break expression and break label are totally different statements, that happen to be spelled similarly  - break is the same statement all around, but just as return requires a value in a value-returning method and requires no value in

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

The rest of it is about where to put the sharp edges:  Can I break-e from a switch-e wherever I might consider doing return from a method/lambda?  Or does break-e have extra restrictions to prevent certain ambiguities?  Your answer is the latter. Right.  To avoid ambiguity with other breaky c

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

On Mar 23, 2018, at 1:33 PM, Brian Goetz wrote: > >> i just realized that the X-heavy first column also means that I can't >> make use of statement labels *anywhere inside* of e-switch, even >> if I just copy-and-pasted self-contained code from elsewhere. > > No, you can do this: > > e-swit

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

String s = switch (e) { case 0 -> break “foofoo”; case 1: if (p == 0) break x; else { String z = hairy(x); break z+z; } case 2 -> “barbar”; }; Now I decide that case 1 has three subcases. So I change the `if` to a statement `switch`.

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

It seems to me that your argument cuts in a different direction: If the important risk is that users can't be sure what "break X" means without a non-local scan, we should absolutely require the parentheses. I think that's a reasonable conversation -- but it wouldn't make me any more intere

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

On Mar 23, 2018, at 1:20 PM, John Rose wrote: > > I think mandating "break (e)" is a lighter > weight solution, even though it has some of the > #{ Stand Out }# smell. > > — John P.S. And to be clear, I'm simply pointing out surprising consequences of your design, to elucidate its trade-offs.

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

On Mar 23, 2018, at 12:58 PM, Brian Goetz wrote: > > In exchange, the cost on all readers is high, because they can't be sure > about what "break X" means. Why burden all users with this complexity? Why > spend any of our complexity budget on such a low-leverage option? It seems to me that y

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

I think the burden should go the other way -- we should justify why such flexibility is warranted, and I think this is difficult to do. The conditions under which such control flow are useful are already small, and further, when you might want to code like that, the expression switch form offe

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

On Mar 23, 2018, at 12:41 PM, Brian Goetz wrote: > > I think so. Its not detecting the ambiguity, its that the possibility of > mixing control flow kinds means the poor reader has to reason about all the > possibilities, and not be sure what "break FOO" means in a switch statement. A lighter

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

The symptom of this design choice is the large number of X entries in the break-e column, where there are few X entries in the return column. I suppose you are aiming in this direction to reduce occasional ambiguities between break-e and break-l.  But such ambiguities can be controlled in othe

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

On Mar 23, 2018, at 11:45 AM, Brian Goetz wrote: > > More formally; we can construct a table whose rows are the control constructs > and whose columns are the nonlocal branches, and whose entries are "handlers" > for a nonlocal branch. Each block has a parent (the immediately enclosing > bloc

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

See comments in two places below. > On Mar 23, 2018, at 2:45 PM, Brian Goetz wrote: > > Just want to sync and make sure we're on the same page here... > > Certain constructs (switch expression, switch statement, for/while/do) give > meaning to some flavor of break. Inside those, you can't use

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

Just want to sync and make sure we're on the same page here... Certain constructs (switch expression, switch statement, for/while/do) give meaning to some flavor of break.  Inside those, you can't use the other flavor, nor can you break "through" a construct of the opposite flavor.     switc

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

Jan has updated the prototype to make the switch expression a bubble penatrable only by exceptions.  Please take a look! On 3/2/2018 9:30 AM, Remi Forax wrote: Hi all, as far as i remember, the current idea to differentiate between a break label and a break value is to let the compiler figure

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

> 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 &q

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

ke it :) Rémi > De: "Kevin Bourrillion" > À: "Brian Goetz" > Cc: "Remi Forax" , "amber-spec-experts" > > Envoyé: Vendredi 2 Mars 2018 17:40:05 > Objet: Re: Disallowing break label (and continue label) inside an expression > switch

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

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

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

Thanks for bringing this up.  I remember it being discussed once before, but I don't think we acted on it. I agree that expression switch is an expression, and it should either yield a value or throw something; breaking out of the middle of an expression is not something we have, nor does it s