> From: "Brian Goetz" <brian.go...@oracle.com>
> To: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts@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.go...@oracle.com |
>>> <brian.go...@oracle.com> ]
>>> To: "amber-spec-experts" [ mailto:amber-spec-experts@openjdk.java.net |
>>> <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)
