Fw: JEP 455: Non-enhanced switch statements

[Maurizio Cimadamore]

No disagreement here. But I'd still point out that I'd rather see 
exhaustiveness being associated with the type being switched on, rather 
than on whether the switch body happens to use certain features or not.

For sealed types we're lucky, because switching on them wasn't possible 
before - so if those get exhaustive, fine.

But I'm not sure making a switch statement on e.g. an Object selector 
exhaustive simply because it's a "new form" is necessarily useful? I 
think exhaustiveness is the most useful when there's a fixed amount of 
things to check.

Maurizio

On 27/10/2023 15:33, Brian Goetz wrote:
>
>> Sure - but this logic is only applied to switch expression featuring 
>> enums AFAIK - switch statements with enums are non-exhaustive (and I 
>> think that will have to stay that way).
>
> Slight correction: switch statements on enum selectors *that don't use 
> patterns or guards or case null* are non-exhaustive.  IOW, the current 
> carve-out for non-exhaustiveness is "if you don't use any of the new 
> switch features."
>
> As to "will have to stay that way", I guess it depends on timeframe.  
> I can see a path of gradually increasing warnings ("totalize that 
> switch with a default clause, dude") turning to error in a decade or so?