Pattern matching for switch (Third Preview)

[Tesla Zhang]

Hi Brian,


Thanks for the quick reply! Two more small things:


0. I also see the `<>` in https://openjdk.java.net/jeps/8282272 as well :/
1. Is the 'allow null' thing aimed at adding `null` to all possible switches, so we cannot have empty switches (as `null` becomes an always-possible case candidate)?


Best regards,
Tesla


------------------ Original ------------------
From:                                                                                                                        "Brian Goetz"                                                                                    <brian.goetz at oracle.com>;
Date: Thu, Mar 24, 2022 03:02 AM
To: "Tesla Zhang"<ice1000kotlin at foxmail.com>;"amber-dev"<amber-dev at openjdk.java.net>;

Subject: Re: Pattern matching for switch (Third Preview)





> 0. I noticed a `<&gt;` operator, is that a typo?

Likely a rendering artifact; the markdown renderer in the bug system is 
different from that of the OpenJDK website, which ultimately is the 
definitive view.

> 1. What's the motivation of replacing `??` with a new soft keyword? What's bad about `??`?

This was discussed on the amber-spec-experts list in January; see 
threads rooted at "reviewing feedback on patterns in switch".  The key 
part of this change is not the syntactic change from && to `when`, but 
moving the refinement from the pattern itself, to the switch.  The 
change in syntax follows naturally from this change in location.

FWIW, adjoining guards to patterns has some nasty surprises lurking, 
which we knew about but convinced ourselves we could ignore at first.  
For example, if we ever have switches over boolean (which we surely 
will, as pattern matching has been a forcing function for regularizing 
all aspects of switch, and this one will surely come), you can then get 
some bizarre combinations, which don't mean what you think they mean, like:

     switch (aBoolean) {
         case false && false:  // will never be selected!
         ...
     }

In the design discussion for this feature, we went back and forth 
several times between refining patterns and refining switch cases, since 
there were pros and cons of each.  In the end, it felt like refinement 
fit more cleanly in the conditional construct (switch) than in the 
pattern machinery.  This is why we do previews; to give decisions a 
chance to settle.