<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 23/04/2021 16:38, Brian Goetz wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:9ca67b52-70a1-b0a3-7da0-da96fa5d80ab@oracle.com"><font size="+1"><font face="monospace"><font size="+1"><font face="monospace"><font size="+1"><font face="monospace">So,
                  I think the "a switch only accepts null if the letters
                  n-u-l-l are present", while a comforting move in the
                  short term, buys us relatively little, and dulls our
                  pain receptors which in turn makes it take way longer
                  to learn how patterns really work.  I think we should
                  go back to:<br>
                  <br>
                   - A switch accepts null if (a) one of the case labels
                  is `null` or (b) the switch has a total pattern (which
                  must always be the last case.)  </font></font></font></font></font></font></blockquote>
    <p><font size="+1"><font face="monospace">The proposal seems ok; it
          does nothing for the problem I'm concerned about (e.g. type of
          the target expression changing and influencing the totality
          analysis at a distance) - but that was not address by the
          previous proposal either (as you say in your email,
          admittedly, I was reading too much into your proposal).</font></font></p>
    <p><font size="+1"><font face="monospace">Stepping back - my general
          feeling on this topic is that the audience in this mailing
          list have a very intimate knowledge of what a "total pattern"
          is, to the point that they are comfortable building on top of
          this definition to e.g. define null behavior of patterns. I'm
          a little afraid that the finer detail of totality might be
          lost on the average Joe developer: totality is a much more
          slippery concept than it seems. Sure, there is one obvious way
          to make your pattern total: if the target expression has type
          E, then add a type test pattern whose type is also E. That
          seems easy enough. Except that, the type of E will not always
          be that manifest in user code (e.g. might be the result of
          what javac happens to infer on Tuesdays). And, if you mix this
          with sealed classes, it might be possible for a switch to go
          from total to non-total, as new permitted subtypes are added
          to a sealed hierarchy. These might all be all corner cases -
          but I think it's this complexity which contributes to my
          "isn't this all too subtle?" feeling.</font></font></p>
    <p><font size="+1"><font face="monospace">Obviously I'm well aware
          that nearly every path has been explored, and no silver bullet
          seems to be laying around, so... this might just be the best
          we can offer, and that's ok.<br>
        </font></font></p>
    <p><font size="+1"><font face="monospace">Cheers<br>
          Maurizio<br>
        </font></font></p>
    <p><font size="+1"><font face="monospace"><br>
        </font></font></p>
    <p><font size="+1"><font face="monospace"><br>
        </font></font></p>
  </body>
</html>