[External] : Re: Reviewing feedback on patterns in switch
Brian Goetz
brian.goetz at oracle.com
Wed Feb 16 16:03:19 UTC 2022
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>
More information about the amber-spec-experts
mailing list