<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <blockquote type="cite" cite="mid:445101940.9418309.1646070225203.JavaMail.zimbra@u-pem.fr">
      <div style="font-family: arial, helvetica, sans-serif; font-size:
        12pt; color: #000000">
        <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>
            So *of course* there's an obvious definition of how `int x`
            matches against Integer, and its not a question of whether
            we "define" it that way, its a question of whether we expose
            the obvious meaning, or suppress it.  I think the arguments
            in favor of suppression are pretty weak.</blockquote>
          <div><br>
          </div>
          <div>The strong argument is that instanceof/switch case is
            about subtyping relationship while assignment is about
            assignment conversions, trying to blur the lines between the
            two has already been tried in the past and it results in
            pain (see below). <br data-mce-bogus="1">
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    This is pretty much assuming your conclusion, and then stating it as
    justification :)<br>
    <br>
    I get it; you would prefer that pattern matching be *only* about
    subtyping.  I understand why you prefer that.  But I think this is
    mostly a "retreat to the comfort zone" thing.  <br>
    <br>
    <blockquote type="cite" cite="mid:445101940.9418309.1646070225203.JavaMail.zimbra@u-pem.fr">
      <div style="font-family: arial, helvetica, sans-serif; font-size:
        12pt; color: #000000">
        <div data-marker="__QUOTED_TEXT__"><br>
          <div>What about ?<br data-mce-bogus="1">
          </div>
          <div><br data-mce-bogus="1">
          </div>
          <div>Object o =...<br data-mce-bogus="1">
          </div>
          <div>if (o instanceof byte) { ... }<br>
            <br>
          </div>
          <div>Does it means that o can be a Long ?<br data-mce-bogus="1">
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    This is a good question.  (But I know it's also a trap.)  We first
    have to ask about (static) applicability: is the pattern `byte b`
    applicable to Object?  If not, we'll get a compilation error.  <br>
    <br>
    My earlier message said: <br>
    <br>
    <font size="4"><font face="monospace"> - A primitive type pattern `P
        p` should be applicable to a reference target T if T unboxes to
        P, or T unboxes to a primitive type that can be widened to P [
        or if T unboxes to a primitive type that can be narrowed to P. ]<br>
        <br>
        Does Object unbox to byte?  No.<br>
        Does Object unbox to a primitive type that can be widened to
        byte?  No.<br>
        [brackets] Does Object unbox to a primitive type than can be
        narrowed to byte?  No.<br>
        <br>
        How does this square with assignments?  I cannot assign<br>
        <br>
            byte b = anObject<br>
        <br>
        |  incompatible types: java.lang.Object cannot be converted to
        byte<br>
        <br>
        If I try this with casting:<br>
        <br>
           Object o = 0L<br>
           byte b = (byte) o<br>
        <br>
        I get a CCE, because the cast will only convert from Byte.<br>
        <br>
        Now, what if instead of Object, we start with Long?  <br>
        <br>
            Long l = 0L<br>
            if (l instanceof byte b) { ... }<br>
        <br>
        First, applicability: does Long unbox to a primitive type that
        can be narrowed to byte?  Yes!  Long unboxes to long, and long
        can be narrowed to byte.  <br>
        <br>
        Then: matching: if the RHS is not null, we unbox, and do a range
        check.  (The rules in my previous mail probably didn't get this
        case perfectly right), but 0L will match, and 0xffff will not --
        as we would expect.  <br>
        <br>
        <br>
        We could consider pushing this farther, if we liked, but there's
        a risk of pushing it too far, and I think we're already on the
        cusp of diminishing returns.  We could consider `case byte b`
        against Object to match a Byte.  We discussed this, in fact, a
        few years ago when we talked about "what does `case 0` mean"
        when we were considering constant patterns.  (And we concluded
        in that discussion that the step where we basically treat Long
        as narrowable to Integer was taking it way too far.)  So I think
        the rules I've specified capture (a) the right set of tradeoffs
        of how loose we want to be with regard to boxing/unboxing
        combined with narrowing/widening, subject to (b) the existing
        decisions we've made about assignments.  <br>
        <br>
        <br>
        <br>
        <br>
      </font></font><font size="4"><font face="monospace"></font></font>
  </body>
</html>