# New JEP: Switch Expressions for the Java Language

Brian Goetz brian.goetz at oracle.com
Mon Dec 18 21:25:15 UTC 2017


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20171218/6c70b74b/attachment-0001.html>