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: expression switch vs. procedural switch

On Mar 13, 2018, at 2:57 PM, Remi Forax wrote: > > it's perhaps me, but i think that Kevin saying that he wants to discourage > side effects, not disable them, avoiding side effects like it.next() is not > possible in Java. > > We already have this kind of discussion when

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

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

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