Of course, in an ecosystem as diverse as Java developers, one routinely expects to get complaints about both X and ~X.  Which makes it notable that we have not gotten any complaints about "why do you force me to write an empty default".  (I'm not complaining!)

The case you raise -- legacy { switch type, labels, statement } switches -- is harder to fix.  The things we've explored (like an opt-in to totality) are pretty poor fixes, since (a) they are noisy warts, and (b) people will forget them and still have the problem.  So these are harder, longer-term problems.  (For now, the best we can do is noisy warnings.)

On 2/16/2022 11:00 AM, Remi Forax wrote:


------------------------------------------------------------------------

    *From: *"Brian Goetz" <brian.go...@oracle.com>
    *To: *"amber-spec-experts" <amber-spec-experts@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)




Reply via email to