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?
