New JEP: Switch Expressions for the Java Language

[Brian Goetz]

On 12/18/2017 4:16 PM, Kevin Bourrillion wrote:
> On Mon, Dec 11, 2017 at 11:28 AM, Brian Goetz <brian.goetz at oracle.com 
> <mailto:brian.goetz at oracle.com>> wrote:
>
>>     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.
>
>
> There is a problem here, especially among users who learn Java in the 
> future and never know how `switch` used to work.
> They will know that `null` is a valid thing to switch on, and when 
> they don't see `case null` they will assume that the `default` clause 
> is being executed. That's unfortunate.
>

Why would they assume that?  What they'll learn in future Java school is 
"If there's no explicit case null, switch throws NPE". Which is exactly 
as it is today -- except that you can't spell "case null".  In no case 
will a switch without a "case null" execute the default clause on null 
input.

> Now whenever we want null handled the default way we're going to have 
> to do this:
>
> case null:
> default:
>   codeHere();

Right.  This seems pretty clean to me -- if you want null lumped into 
default, you say so, and its clear.  Otherwise you get the default null 
treatment.

> This isn't an absolute deal-breaker, but I could use a refresher on 
> what the positive value of allowing `case null` is at all. The word 
> "null" does not appear in the current pattern matching doc.

Same answer as with floats: nested patterns and composibility.

Suppose I have a class Box<T>, which is a one-element collection, and 
let's say a Box can contain null.  (Nulls are reasonable, if tricky 
values for domain classes.)  I want to be able to say:

     case Box(null): ...

which is a nested pattern that means:

     case Box(\alpha) where \alpha matches null:

which brings us back to: everything is cleaner if null is a just 
constant pattern that can be matched.  At which point, it just seems a 
little mean to have null be a pattern but *not* be able to say:

     case null:

in a switch at top level.  Especially because you should be allowed to 
refactor:

     case Box(null): A
     case Box(String s): B;
     case Box(Frogs fs): C;

into

     case Box(var x):
         switch (x) {
             case null: A
             case String s: B;
             case Frogs fs: C;
         }

if that seems beneficial.