New JEP: Switch Expressions for the Java Language

Brian Goetz brian.goetz at oracle.com
Mon Dec 11 19:28:17 UTC 2017


> Reading the original proposal.
>
> First, I think it's great. I think a lot of existing switches would 
> look nicer as expression switches.

... and be less error-prone.

>
> I think most of my questions surround how these changes will (or 
> /should/) affect non-expression switches.
>
>   * Should we retcon `case A, B:` onto regular switches, with the same
>     semantics?
>
Absolutely; I thought this was already present in the JEP, but if not, 
I'll clarify.

>   * Should we retcon `case null:` onto regular switches, with the same
>     semantics?
>

Absolutely; same comment.

>   * 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.
>

I think this sort of falls out for free; expressions are generally 
usable as statements, unless we can't determine their standalone type 
(like lambdas).  However, I'm not sure this would be good practice.


>   * Allowing `throw` as the RHS of a case makes sense, but let's
>     carefully think through the ramifications of making it an
>     expression in general. Do we really want to see code like this?
>
>     void foo(Bar bar) {
>       bar.isValid() || throw new IllegalArgumentException();
>     }
>

OK, let's pull on that string.  The next logical place for it is 
conditional expressions:

     String s = (x >= 0) ? Integer.toString(x) : throw new IAE();

This seems pretty reasonable too, though the if-else version is not 
horribly broken either.  What about conditionals in method invocation 
context:

     m(x > 0 ? Integer.toString(x) : throw new IAE())

I know I've wanted to be able to do this at times, though again, I've 
worked around it and lived, and surely it could be abused.

I'm OK cutting this one back.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20171211/f5bfe3d0/attachment.html>


More information about the amber-spec-experts mailing list