New JEP: Switch Expressions for the Java Language

Kevin Bourrillion kevinb at google.com
Mon Dec 18 21:16:07 UTC 2017


On Mon, Dec 11, 2017 at 11:28 AM, Brian Goetz <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.

Even for those of us who have been around, we have always seen

  case ANYTHING:
  default:
    codeHere();

as a weird thing to do. Now whenever we want null handled the default way
we're going to have to do this:

  case null:
  default:
    codeHere();

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.

(I will be digging up stats on the prevalence of "faking" a null case with
`if`, but I suspect it's not very much.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20171218/0bb7e053/attachment.html>


More information about the amber-spec-experts mailing list