New JEP: Switch Expressions for the Java Language

[Brian Goetz]

Here’s another way of looking at expression switch.  This is a translation-centric view, but may be useful both as a mental model and as a specification approach as well. 

If I have an expression switch:

    T y = switch (x) {
        case A -> e;
        case B -> f;
    }

We could implement by desugaring the switch into the invocation of a synthetic method:

    T y = m$switch(x, a, b, ...)

where a, b, ... are locals mentioned in e and f.  And m$switch() is:
 - replace "case L -> e" with "case L: return e"
 - replace case L -> block with "case L: block"**
 - m$switch() is declared to throw any checked exceptions thrown by switch arms.

** This is exploiting the otherwise-unfortunate pun between local return and nonlocal return.


Where does this leave us?

 - Can't do nonlocal return out of an expression switch.  That's good -- that's what we wanted anyway.
 - Can't reference mutable locals.  That seems OK, but see below.  
 - Fallthrough in expression switches (other than OR patterns) is cleverly prohibited by the syntax of switch expressions.  

This mental model leaves us pretty close to where we thought we wanted to land anyway (whether or not we actually translate like this.)

Note that the “effectively final” constraint is stronger than it needs to be to support this model.  The reason that captured locals of even stack-confined lambdas need to be effectively final is that the capture point and the invocation point of the lambda might be different, and so there would be two credible answers for what the following program could print:

    int x = 3;
    Runnable r = () -> println(x);

    x = 4;
    r.run();

You could argue for either 3 or 4 here, so to eliminate the potential for confusion (among other reasons) we say “no non-effectively-final captures”.  But, for an expression switch desugared as above, the capture point and invocation point are guaranteed to be the same.  So we could easily say that its OK to reference (but not mutate) mutable locals in a switch expression, and it would be consistent with the model given.  

Note that “consistency” offers us no guidance here; in one approach we’re consistent with lambdas but inconsistent with, say, conditional expressions (which can reference and even mutate mutable locals.)  

So, candidates for what happens here:
 - like conditional expression — anything goes, locals can be mutated
 - can read locals, but can’t write them — a reasonable position, but unlike anything else so far
 - like lambdas - effectively final locals only.




> On Dec 7, 2017, at 5:33 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> We've separated out a package of standalone improvements to `switch` (switch expressions, case null, and case alternation) into their own JEP:
> 
>     https://bugs.openjdk.java.net/browse/JDK-8192963
> 
> 

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