<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4"><font face="monospace">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.</font></font><br>
    <br>
    <div class="moz-cite-prefix">On 10/29/2023 3:01 PM, Angelos
      Bimpoudis wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:IA1PR10MB75155B171F1A79AF5745AE0282A2A@IA1PR10MB7515.namprd10.prod.outlook.com">
      
      <style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
      <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>
      <hr style="display:inline-block;width:98%" tabindex="-1">
      <div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b>
          amber-spec-experts <a class="moz-txt-link-rfc2396E" href="mailto:amber-spec-experts-retn@openjdk.org"><amber-spec-experts-retn@openjdk.org></a>
          on behalf of Maurizio Cimadamore
          <a class="moz-txt-link-rfc2396E" href="mailto:maurizio.cimadamore@oracle.com"><maurizio.cimadamore@oracle.com></a><br>
          <b>Sent:</b> 27 October 2023 16:37<br>
          <b>To:</b> Brian Goetz <a class="moz-txt-link-rfc2396E" href="mailto:brian.goetz@oracle.com"><brian.goetz@oracle.com></a>;
          <a class="moz-txt-link-abbreviated" href="mailto:amber-spec-experts@openjdk.org">amber-spec-experts@openjdk.org</a>
          <a class="moz-txt-link-rfc2396E" href="mailto:amber-spec-experts@openjdk.org"><amber-spec-experts@openjdk.org></a><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>
    </blockquote>
    <br>
  </body>
</html>