New JEP: Switch Expressions for the Java Language

[Kevin Bourrillion]

Reading the original proposal.

First, I think it's great. I think a lot of existing switches would look
nicer as expression switches.

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?
   - Should we retcon `case null:` onto regular switches, with the same
   semantics?
   - 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.
   - 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();
   }




On Mon, Dec 11, 2017 at 1:10 PM, Kevin Bourrillion <kevinb at google.com>
wrote:

>
>
> On Sun, Dec 10, 2017 at 2:40 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
> So, speaking semantically only:
>>  - We should not allow fall through in expression switch; I don’t think
>> it makes any sense.
>>  - I’m pretty convinced that nonlocal returns out of expression switch
>> (other than throwing) is similarly a wrong fit.  (We allow this in neither
>> conditional expressions nor lambdas.)
>>  - Switch expressions should definitely be able to reference locals, but
>> we’re open minded to some restrictions (such as no mutation).
>>  - We could justify allowing switch expressions to mutate locals, since
>> other expressions can too, but we could similarly justify restricting
>> mutation
>>  - More strongly, we could justify restricting even referencing
>> non-eff-final locals, though this is starting to get onto thin ice, because
>> the only argument we have for this is “for (superficial) consistency with
>> lambdas”, which is pretty weak.
>>
>
> I believe I agree on all points. I think replacing : with -> is a very
> nice fit even if it's slightly more permissive than a lambda. Being just as
> restrictive does not seem justified.
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
>



-- 
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/ef2b1ed3/attachment-0001.html>