Pattern matching for switch (Third Preview)

[Tesla Zhang]

Hi Brian,


Very nice!!! This is exactly the design that makes the most sense to me. Thank you people for the great work!!


Btw, I think it would be nice to have less keywords, so what about reusing `if` instead of introducing the new contextual keyword `when`? This should probably help with parsing (and since `if` works only in statements, this is probably unambiguous both for the compiler and to a human).


Best regards,
Tesla


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

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




> 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)?

No.

Historically, switches are null-hostile.  This was a mostly sensible 
choice when the reference types that switch accepted were (a) very 
limited and (b) types for which null was almost certainly an error 
(e.g., Integer), but as switch gets more general, this restriction 
increasingly appears arbitrary.  We are constrained by compatibility to 
retain the legacy behavior, so the new treatment of null is effectively 
opting into null by saying "case null" somewhere in the switch.  An 
empty switch has no "case null".  And even if it were, null would fall 
into the "remainder" (just as novel subclasses of sealed types are, as 
well as some other weird shapes) and be rejected via remainder rejection.

So the null treatment does not interact with exhaustiveness checking in 
any meaningful way.