New JEP: Switch Expressions for the Java Language

[Kevin Bourrillion]

On Mon, Dec 11, 2017 at 11:28 AM, Brian Goetz <brian.goetz at oracle.com>
wrote:

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

To be more clear, I think what I'm asking is whether we would permit cases
to not produce a value, if the entire switch were not being used as an
expression. Doing this would kind of sort of make the original switch
statement relatively obsolete. That feels weird, but on the other hand,
maybe being able to consistently use new-style switches more and more of
the time would be a good thing?

Just thinking out loud here.


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

This is like a buried lede. A major function of this statement is to make
your entire method bomb out if x is negative - but that's randomly embedded
inside some method call site. I don't think I like this.



> I'm OK cutting this one back.
>



-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20171211/5d536b45/attachment-0001.html>