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

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Wednesday, February 16, 2022 5:03:19 PM
> Subject: Re: [External] : Re: Reviewing feedback on patterns in switch

> 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.)
The problem of the noisy warning is that there is no "right" way to fix the warning now. 
Adding a default is not what we want, we need a way to opt-in exhaustiveness. 
But we never agree on the way to do that. 

Rémi 

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

>>> From: "Brian Goetz" [ mailto:brian.goetz at oracle.com | <brian.goetz at oracle.com> ]
>>> To: "amber-spec-experts" [ mailto:amber-spec-experts at openjdk.java.net |
>>> <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/0a6cd764/attachment.htm>