[switch] Further unification on switch

2018-04-19 Thread Brian Goetz
We've been reviewing the work to date on switch expressions. Here's where we are, and here's a possible place we might move to, which I like a lot better than where we are now. ## Goals As a reminder, remember that the primary goal here is _not_ switch expressions; switch expressions are supp

Re: [switch] Further unification on switch

2018-04-19 Thread Guy Steele
> On Apr 19, 2018, at 4:44 PM, Brian Goetz wrote: > > We've been reviewing the work to date on switch expressions. Here's where we > are, and here's a possible place we might move to, which I like a lot better > than where we are now. > . . . > ## Closing the gap > > So, let's take one more s

Re: [switch] Further unification on switch

2018-04-19 Thread Doug Lea
I was starting to get fatalistically pessimistic about switch, but the all-colon-as-statement vs all-arrow-as-expression idea (with nothing in-between) seems pretty good! And would be even better if JLS impact were carefully checked. -Doug On 04/19/2018 04:44 PM, Brian Goetz wrote: > We've been

Re: Expression switch exception naming

2018-04-19 Thread Brian Goetz
I like Un{recognized,known}EnumConstantE{rror,xception}.  When we get to sealed types, it will be the same but with something like s/EnumConstant/SealedTypeMember/. I am still having trouble squaring the Error vs Exception, but you've pulled me from "seems like an Exception to me" into "crap,

Re: [switch] Further unification on switch

2018-04-19 Thread John Rose
On Apr 19, 2018, at 1:44 PM, Brian Goetz wrote: > > The result is one switch construct, with modern and legacy flavors, which > supports either expressions or statements. +10 Incrementally improving existing constructs is better, in this case (and usually) than piecemeal adding new-but-similar

Re: [switch] Further unification on switch

2018-04-19 Thread Brian Goetz
Can a single-statement case have a variable declaration as that statement, and what would be its scope? No, a local variable declaration is a BlockStatement (JLS 14.2), not a Statement (JLS 14.5).  So you could say:     case FOO -> println(3); or     case FOO -> {     int x = 4;    

Re: [switch] Further unification on switch

2018-04-19 Thread Guy Steele
> On Apr 19, 2018, at 6:19 PM, Kevin Bourrillion wrote: > . . . > Can a single-statement case have a variable declaration as that statement, > and what would be its scope? My guess would be “yes”, and all the same things would happen as for a local variable declaration statement that happens t

Re: [switch] Further unification on switch

2018-04-19 Thread Guy Steele
> On Apr 19, 2018, at 6:27 PM, Brian Goetz wrote: > > >> >> Can a single-statement case have a variable declaration as that statement, >> and what would be its scope? > > No, a local variable declaration is a BlockStatement (JLS 14.2), not a > Statement (JLS 14.5). So you could say: > >

Re: Expression switch exception naming

2018-04-19 Thread Brian Goetz
> I think I do finally understand, thanks to your example, what is different > between this and the previous kinds of incompatible changes. The JDK (and > some libraries) makes strong promises not to break compatibility. Yet we > simply can't throw up our hands and refuse to add constants to enu