Fw: JEP 455: Non-enhanced switch statements

[Brian Goetz]

At the same time, we should consider a lint warning for non-exhaustive 
old-style switches, which a recommendation to make them exhaustive with 
`default:` or `default -> {}`, depending on the switch style.

On 10/29/2023 3:01 PM, Angelos Bimpoudis wrote:
> I am now a bit more convinced that freezing the old handling at the 
> old spec is a clean approach. The new data types confirm the presence 
> of an enhanced switch. So, the behaviour of the patch was a feature in 
> the end (I will adjust the spec of course--the place that Yuriy 
> pointed us to).
>
> Supporting the new types to the old-style switch with new-style 
> semantics opens questions about equality (would need to be the same 
> between the old and the new), about a new translation for a 
> not-enhanced switch but supporting the new types with old style 
> semantics. It would be also necessary to avoid the translation with 
> |MatchException|​ which is a feature of the enhanced switch.
>
> We see that there are a lot of consequences for an enhancement that, 
> as Remi says, belongs to the new pattern matching mechanism and not to 
> the old-style switch. This also confirms that old-handling+old spec 
> should not be altered indeed.
> ------------------------------------------------------------------------
> *From:* amber-spec-experts <amber-spec-experts-retn at openjdk.org> on 
> behalf of Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
> *Sent:* 27 October 2023 16:37
> *To:* Brian Goetz <brian.goetz at oracle.com>; 
> amber-spec-experts at openjdk.org <amber-spec-experts at openjdk.org>
> *Subject:* Re: Fw: JEP 455: Non-enhanced switch statements
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20231029/fa28081d/attachment-0001.htm>