Fw: JEP 455: Non-enhanced switch statements

[Angelos Bimpoudis]

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/a54e358f/attachment.htm>