New JEP: Switch Expressions for the Java Language

[Brian Goetz]

>
>>   * Should we make it possible to use the new expression switch
>>     construct in non-expression contexts? Any values returned by a
>>     case would be ignored. Optionally we could skip requiring default
>>     to be present (meh). Users may want this because it's really nice
>>     to not have to write "break" anymore. They may also want it if we
>>     answer "no" to either or both of the previous two questions. It's
>>     also kind of nice that each case gets its own separate scope,
>>     although they can get that by inserting braces anyway.
>>

In order for it not to be painful to turn a statement switch into an 
expression switch, we'd have to support void-typed expression switches.  
Then you could write something like this:

     switch (target) {
         case X -> println("x");
         case Y -> println("y");
     }

But expressions can't have void type (among other reasons, it's not a 
type, at least not yet), so we'd have to carve out a special case for 
this if we wanted to support it.  And this would further muddy the 
differences, and call for a number of other special cases (e.g., how 
would I write the default clause?)

So as long as we don't bend over backwards to try and special-case void 
expression switches (we don't for conditional expressions), I think 
"there's expression switch and statement switch; using either to 
simulate the other is painful, so don't" leads to a good place.

(Note to observers: the goal of this exercise here is not to fix what 
people hate about statement switch; it's about (a) laying the groundwork 
for pattern matching while (b) factoring out some generally-useful 
enhancements that can be exposed earlier.)




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20171211/b148e390/attachment.html>