New JEP: Switch Expressions for the Java Language

[Kevin Bourrillion]

On Mon, Dec 18, 2017 at 1:25 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

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

I'm with you so far.



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

To me, this amounts to enough justification *if there were no drawbacks*,
but given the potential for some confusion exists, I am still trying to
convince myself why this matters enough to outweigh that.




-- 
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/20171218/9809f437/attachment-0001.html>