Reviewing feedback on patterns in switch

[Remi Forax]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Wednesday, February 16, 2022 4:49:19 PM
> Subject: Re: Reviewing feedback on patterns in switch

> One thing that we have, perhaps surprisingly, *not* gotten feedback on is
> forcing all non-legacy switches (legacy type, legacy labels, statement only) to
> be exhaustive. I would have thought people would complain about pattern
> switches needing to be exhaustive, but no one has! So either no one has tried
> it, or we got away with it...
Yes, we had several feedbacks about the opposite, why the switch statement on an enum is not exhaustive, i.e. why the following code does not compile 

enum Color { RED , BLUE } 
int x; 
Color color = null ; 
switch (color) { 
case RED -> x = 0 ; 
case BLUE -> x = 1 ; 
} 
System. out .println(x);  // x may not be initialized 
Rémi 

> On 1/25/2022 2:46 PM, Brian Goetz wrote:

>> We’ve previewed patterns in switch for two rounds, and have received some
>> feedback.  Overall, things work quite well, but there were a few items which
>> received some nontrivial feedback, and I’m prepared to suggest some changes
>> based on them.  I’ll summarize them here and create a new thread for each with
>> a more detailed description.

>> I’ll make a call for additional items a little later; for now, let’s focus on
>> these items before adding new things (or reopening old ones.)

>> 1.  Treatment of total patterns in switch / instanceof

>> 2.  Positioning of guards

>> 3.  Type refinements for GADTs

>> 4.  Diamond for type patterns (and record patterns)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220216/44fff9b2/attachment-0001.htm>