Re: break seen as a C archaism

> On Mar 16, 2018, at 5:39 AM, Peter Levart wrote: > > Expanding on do… Well, as long as we are fantasizing: > On 03/16/18 09:50, Peter Levart wrote: >> And if "while (false)" could be optional, we get: > > Or better yet, make "while (true)" optional even in statement

Re: break seen as a C archaism

I don't know why others find break so archaic. When I 1st saw this proposal, I thought that break was very intuitive choice for e-switch. I think this is mostly an emotional reaction.  There are plenty of things to dislike about switch in Java; I think that for some, the prospect of

Re: break seen as a C archaism

egards, Rémi > De: "Peter Levart" <peter.lev...@gmail.com> > À: "John Rose" <john.r.r...@oracle.com>, "Maurizio Cimadamore" > <maurizio.cimadam...@oracle.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>

Re: break seen as a C archaism

Expanding on do... On 03/16/18 09:50, Peter Levart wrote: And if "while (false)" could be optional, we get: Or better yet, make "while (true)" optional even in statement do, so we can finally get away with some more boilerplate: for (;;) { } or while (true) { } and simply do: do { }

Re: break seen as a C archaism

Hi, May I jump in as an outsider and someone who's just using the language... On 03/15/18 22:58, John Rose wrote: On Mar 15, 2018, at 2:13 PM, Maurizio Cimadamore > wrote: So, from a language design perspective, 'return

Re: break seen as a C archaism

.com> >> Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> >> <mailto:amber-spec-experts@openjdk.java.net> >> Envoyé: Jeudi 15 Mars 2018 23:06:51 >> Objet: Re: break seen as a C archaism >> On Mar 15, 2018, at 2:44 PM, Guy Steele

Re: break seen as a C archaism

;Guy Steele" <guy.ste...@oracle.com> *Cc: *"amber-spec-experts" <amber-spec-experts@openjdk.java.net> *Envoyé: *Jeudi 15 Mars 2018 23:06:51 *Objet: *Re: break seen as a C archaism On Mar 15, 2018, at 2:44 PM, Guy Steele <guy.ste...@oracle.com <

Re: break seen as a C archaism

> De: "John Rose" <john.r.r...@oracle.com> > À: "Guy Steele" <guy.ste...@oracle.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Jeudi 15 Mars 2018 23:06:51 > Objet: Re: break seen as a C archais

Re: break seen as a C archaism

Okay, Maurizio, you got me thinking. As long as we are convinced that we are actually going to use an explicit value-returning statement within a switch expression quite infrequently in real code, why don’t we get the best of both worlds by spelling it this way: break return x; Then

Re: break seen as a C archaism

On Mar 15, 2018, at 2:13 PM, Maurizio Cimadamore wrote: > > So, from a language design perspective, 'return x' is wrong - but, as you > point out, we already committed the original sin of having 'return == local > return' for lambdas, so I'm not too convinced

Re: break seen as a C archaism

- Mail original - > De: "mark" <m...@io7m.com> > À: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Jeudi 15 Mars 2018 20:06:40 > Objet: Re: break seen as a C archaism > On 2018-03-15T14:50:45 -0400 > Brian Go

Re: break seen as a C archaism

r-spec-experts@openjdk.java.net> >> Envoyé: Jeudi 15 Mars 2018 20:18:34 >> Objet: Re: break seen as a C archaism > >>> On Mar 15, 2018, at 3:06 PM, Mark Raynsford <m...@io7m.com> wrote: >>> >>> On 2018-03-15T14:50:45 -0400 >>> Bri

Re: break seen as a C archaism

- Mail original - > De: "Guy Steele" <guy.ste...@oracle.com> > À: "Brian Goetz" <brian.go...@oracle.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Jeudi 15 Mars 2018 20:12:56 > Objet: Re: br

Re: break seen as a C archaism

- Mail original - > De: "Guy Steele" <guy.ste...@oracle.com> > À: "mark" <m...@io7m.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Jeudi 15 Mars 2018 20:18:34 > Objet: Re: break seen as

Re: break seen as a C archaism

> On Mar 15, 2018, at 3:06 PM, Mark Raynsford wrote: > > On 2018-03-15T14:50:45 -0400 > Brian Goetz wrote: >> >>> If you are reconsidering options, reconsider "yield", meaning >>> "break current context with this value". >> >> Still feeling a little

Re: break seen as a C archaism

On Mar 15, 2018, at 11:11 AM, Brian Goetz wrote: > We had rejected this earlier for fairly obvious reasons, but let me > ask to get a subjective response: would using "return x" be better? > On the one hand, it's not really a return, and it doesn't build on the > user

Re: break seen as a C archaism

> On Mar 15, 2018, at 2:50 PM, Brian Goetz wrote: > > >>> We had rejected this earlier for fairly obvious reasons, but let me >>> ask to get a subjective response: would using "return x" be better? >> If you are reconsidering options, reconsider "yield", meaning >>

Re: break seen as a C archaism

On 2018-03-15T14:50:45 -0400 Brian Goetz wrote: > > > If you are reconsidering options, reconsider "yield", meaning > >"break current context with this value". > > Still feeling a little burned by first time we floated this, but willing > to try another run up the

Re: break seen as a C archaism

On 03/15/2018 02:11 PM, Brian Goetz wrote: >> - That we are overloading an existing control construct, "break", >> to mean something just different enough to be uncomfortable; >> >> >> To some degree yes, since `break ` already means >> something. > > We had rejected this earlier for fairly

Re: break seen as a C archaism

Just to make sure we have some numbers when talking about fallthrough: - Among all switches, we calculate that 2.4% of switches in the Google codebase have some nontrivial fallthrough. (This is possibly an overestimate due to overly conservative control flow analysis, but not an

Re: break seen as a C archaism

 - That we are overloading an existing control construct, "break", to mean something just different enough to be uncomfortable; To some degree yes, since `break ` already means something. Digging deeper: If we spelled "break " differently (yield, emit, defuse), would it be

Re: break seen as a C archaism

On Mar 14, 2018, at 11:04 AM, Kevin Bourrillion wrote: > > Part of it is the ability to embed a number of statements inside an > expression (please, at least require curly braces, but still). Well, we do, look again! The switch as a whole requires the curlies you want. I'm

Re: break seen as a C archaism

> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Kevin Bourrillion" <kev...@google.com> > Cc: "Louis Wasserman" <lowas...@google.com>, "Remi Forax" <fo...@univ-mlv.fr>, > "amber-spec-experts" <amber-spec-e

Re: break seen as a C archaism

I get what you’re looking for, I really do. Existing switch has a lot of warts, some of which could be avoided with a new expression switch construct. Avoiding warts seems like a good idea, and fall through is _even wartier_ with expression switches than statement switches. (Not sure how you

Re: break seen as a C archaism

There are three arguments why the N case is significantly different from the 2 case. There are a number of idioms that require statements in addition to an expression. Debugging printfs, objects that take statements to initialize (construct/set/set/break), incrementing counters, cases that

Re: break seen as a C archaism

On Tue, Mar 13, 2018 at 5:43 PM, Kevin Bourrillion wrote: But setting aside subjective reactions, are there better alternatives? >> Let's review what has been considered already, and why they've been passed >> over: >> >> - Do nothing; only allow single expressions.

Re: break seen as a C archaism

Sorry for 5,000 inline replies. On Tue, Mar 13, 2018 at 1:18 PM Brian Goetz wrote: Thanks for the detailed analysis. I'm glad to see that a larger percentage > could be converted to expression switch given sufficient effort; > Just to be clear: the sample was only

Re: break seen as a C archaism

Thanks for the detailed analysis.  I'm glad to see that a larger percentage could be converted to expression switch given sufficient effort; I'm also not surprised to see that a lot had accidental reasons that kept them off the happy path.  And, your analysis comports with expectations in

Re: break seen as a C archaism

Did you happen to calculate what percentage was _not_ the "default" case?  I would expect that to be a considerable fraction. On 3/9/2018 5:49 PM, Kevin Bourrillion wrote: On Fri, Mar 9, 2018 at 1:19 PM, Remi Forax > wrote: When i asked what

Re: break seen as a C archaism

I understand where these people are coming from.  But my experience is, with a platform as mature as Java, one must be very, very careful of the desire to opportunistically "fix" "mistakes" of the past, it can be a siren song that draws you to the rocks.  I am skeptical of arguments that "we