<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"amber-spec-experts" <amber-spec-experts@openjdk.java.net><br><b>Sent: </b>Monday, February 28, 2022 3:34:02 PM<br><b>Subject: </b>Re: [External] : Re: Primitive type patterns<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br>
    <blockquote cite="mid:1874101248.9190368.1646052603982.JavaMail.zimbra@u-pem.fr">
      <div style="font-family: arial, helvetica, sans-serif; font-size:
        12pt; color: #000000">
        <div>
          <div><br>
          </div>
          <div>Nope,<br>
          </div>
          <div>i'm saying that inside a pattern if we let the unboxing
            to be possible with the semantics that if the value is null,
            instead of throwing a NPE if it does not match, we are
            introducing the equivalent of the null-safe operator of
            Groovy (the elvis operator),  something we should not do
            (and that was rejected in the past, i think as part of Coin
            or Coin 2).<br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Too silly to respond to.  Let's stay serious, please.  <br>
    <br>
    <blockquote cite="mid:1874101248.9190368.1646052603982.JavaMail.zimbra@u-pem.fr">
      <div style="font-family: arial, helvetica, sans-serif; font-size:
        12pt; color: #000000">
        <div>Maybe it means that we should
          allow unboxing with the semantics that it throw a NPE i.e the
          exact semantics of the assignment conversion instead of
          disallowing unboxing as i proposed, I don't know, but I really
          dislike the semantics you are proposing here.<br>
        </div>
      </div>
    </blockquote>
    <br>
    It seems more likely that you just *don't understand* what is being
    proposed here (and the fact that you keep repeating the incorrect
    claim that pattern matching somehow means different things in
    different constructs underscores that.)  </blockquote><div><br></div><div>[....]<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>It's your view of the world you think that you can subsume all pattern usages by saying that they obey to the assignment conversions and you think you can decompose the unboxing as nullcheck + do not match.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>I believe that you are wrong on both counts, the former results in an over-generalization that will transfer part of the work the compiler does at compile time at runtime and the later means you are choosing in place of the user if it means Integer(int value) or Integer instead of asking.<br></div><div><br data-mce-bogus="1"></div><div>Given that the first point subsumes the second one, i think we should focus on it, first. <br data-mce-bogus="1"></div><div>So with<br></div><div>  record Atom(Object o) { ... }<br data-mce-bogus="1"></div><div>  Atom box = ...;</div><div>  if (o instanceof Atom(byte b)) {<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>  }<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>can box = new Atom(3); matches the pattern at runtime ?<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Rémi</div><div><br data-mce-bogus="1"></div></div></div></body></html>