<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Helvetica Neue", sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" class="elementToProof ContentPasted0">
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).
<div><br class="ContentPasted0">
</div>
<div class="ContentPasted0">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
<code>MatchException</code> which is a feature of the enhanced switch. </div>
<div><br class="ContentPasted0">
</div>
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.<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> amber-spec-experts <amber-spec-experts-retn@openjdk.org> on behalf of Maurizio Cimadamore <maurizio.cimadamore@oracle.com><br>
<b>Sent:</b> 27 October 2023 16:37<br>
<b>To:</b> Brian Goetz <brian.goetz@oracle.com>; amber-spec-experts@openjdk.org <amber-spec-experts@openjdk.org><br>
<b>Subject:</b> Re: Fw: JEP 455: Non-enhanced switch statements</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">No disagreement here. But I'd still point out that I'd rather see
<br>
exhaustiveness being associated with the type being switched on, rather <br>
than on whether the switch body happens to use certain features or not.<br>
<br>
For sealed types we're lucky, because switching on them wasn't possible <br>
before - so if those get exhaustive, fine.<br>
<br>
But I'm not sure making a switch statement on e.g. an Object selector <br>
exhaustive simply because it's a "new form" is necessarily useful? I <br>
think exhaustiveness is the most useful when there's a fixed amount of <br>
things to check.<br>
<br>
Maurizio<br>
<br>
On 27/10/2023 15:33, Brian Goetz wrote:<br>
><br>
>> Sure - but this logic is only applied to switch expression featuring <br>
>> enums AFAIK - switch statements with enums are non-exhaustive (and I <br>
>> think that will have to stay that way).<br>
><br>
> Slight correction: switch statements on enum selectors *that don't use <br>
> patterns or guards or case null* are non-exhaustive. IOW, the current <br>
> carve-out for non-exhaustiveness is "if you don't use any of the new <br>
> switch features."<br>
><br>
> As to "will have to stay that way", I guess it depends on timeframe. <br>
> I can see a path of gradually increasing warnings ("totalize that <br>
> switch with a default clause, dude") turning to error in a decade or so?<br>
</div>
</span></font></div>
</body>
</html>