[External] : Re: Reviewing feedback on patterns in switch

[Brian Goetz]

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.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/77c96d36/attachment.htm>