<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix"><br>
    </div>
    <blockquote type="cite" cite="mid:6367D637-CE41-4502-BD9B-3580FA5970DE@oracle.com">
      
      <div style="font-family: sans-serif;">
        <div class="markdown" style="white-space: normal;"><br>
          <p dir="auto">
            “We won’t necessarily keep the Q forever, but it will help
            us, during<br>
            prototyping, to clearly map all of the places where
            value-ness needs<br>
            to be tracked.” I remember thinking, “OK, but we’ll never
            get rid<br>
            of it; it’s too obviously correct.” </p>
        </div>
      </div>
    </blockquote>
    <br>
    Or, if not too obviously correct, too nuisancefully attractive.  We
    all got comfortable with the Qs, and when it was time to give them
    up, we all resisted (for different reasons.)  For me, what sold me
    here is the degree to which we are aligning with the language model,
    and how it seems a shorter hop from here to enforced `String!`
    putfields and to species.  <br>
    <br>
    <blockquote type="cite" cite="mid:6367D637-CE41-4502-BD9B-3580FA5970DE@oracle.com">
      <div style="font-family: sans-serif;">
        <div class="markdown" style="white-space: normal;">
          <p dir="auto">Another result was yearly struggle sessions
            about how we were ever going<br>
            to handle migration of Optional, LocalDate, etc. I’m
            surprised and glad<br>
            that we have come to a place of maximum erasure, where (a)
            all the places<br>
            where Q-ness needs mapping have been mapped, and yet (b)
            there is now no<br>
            remaining migration problem (despite no investment in
            high-tech API<br>
            bridges).</p>
        </div>
      </div>
    </blockquote>
    <br>
    Indeed, I remember a time when we thought "we might be able to
    migrate Optional to B2, but never to B3", and Kevin thought I was
    crazy to even imagine that.  The various moves have been like the
    rebalancing of an AVL tree; as you rotate left, then the left side
    is unbalanced, and you rotate the left subtree right, and then ...<br>
    <br>
    <blockquote type="cite" cite="mid:6367D637-CE41-4502-BD9B-3580FA5970DE@oracle.com">
      <div style="font-family: sans-serif;">
        <div class="markdown" style="white-space: normal;">
          <p dir="auto">Along the way Dan S. started quietly talking
            about Type Restrictions,<br>
            which seemed (at first) to be some high-tech ceremony for
            stuff that could<br>
            just as easily be spelled with Q’s. I’m glad he persisted,
            because now<br>
            they seem to be the right-sized bucket in which to place the
            Q-signals,<br>
            after Q’s go away.</p>
        </div>
      </div>
    </blockquote>
    <br>
    Yeah, sounded like magic pixie dust at first to me too.  <br>
    <br>
    To me, the huge (implementation-driven) breakthrough was discovering
    that we could effectively scalarize L-value arguments and returns in
    the calling convention, at almost no extra cost over Q.  This
    surprised me, and is what cracked the nut open that we could erase
    more aggressively.  (Thanks Tobias!)  <br>
    <br>
    <blockquote type="cite" cite="mid:6367D637-CE41-4502-BD9B-3580FA5970DE@oracle.com">
      <div style="font-family: sans-serif;">
        <div class="markdown" style="white-space: normal;">
          <p dir="auto">I think one key principle here is to embrace
            erasure, and hide the<br>
            presence of new refinement types from legacy code.</p>
        </div>
      </div>
    </blockquote>
    <br>
    Indeed, the biggest temptation is the "but we can, and it might be
    useful."  Leaving the level of Class (and descriptors) alone and
    working entirely at the next level down feels unnatural.  <br>
    <br>
    <blockquote type="cite" cite="mid:6367D637-CE41-4502-BD9B-3580FA5970DE@oracle.com">
      <div style="font-family: sans-serif;">
        <div class="markdown" style="white-space: normal;">
          <p dir="auto">Here is a complementary principle: In the VM, we
            should choose to support<br>
            exactly and only those refinement types that support
            Valhalla’s prime goals,<br>
            which are data structure improvement (flattening). Since
            |String!| doesn’t<br>
            (yet) have a flattening story, |String!| should not be a
            (VM) representable<br>
            type. </p>
        </div>
      </div>
    </blockquote>
    <br>
    I'd agree, but only if I can add "yet".  We should pathfind through
    the VM using the things we know we need now, but if we can harness
    value set restrictions later, this is a huge step towards aligning
    to the user model, where users will be beating down our door for
    `String!` and either living without it, or with a complex set of
    compiler-inserted, only-mostly-reliable checks.  <br>
    <br>
    <blockquote type="cite" cite="mid:6367D637-CE41-4502-BD9B-3580FA5970DE@oracle.com">
      <div style="font-family: sans-serif;">
        <div class="markdown" style="white-space: normal;">
          <p dir="auto">Why does |checkcast| get extra powers not
            enjoyed by the other two use<br>
            cases? I think the answer is pretty simple: |checkcast| is
            the last<br>
            resort for a Java compiler’s T.S. (translation strategy); if
            some type<br>
            cannot be represented on a VM container (and enforced by the
            verifier)<br>
            then either it cannot be safely cast (leading to “unchecked”
            warnings)<br>
            or else it must be dynamically checked (requiring a
            |checkcast|).</p>
        </div>
      </div>
    </blockquote>
    <br>
    Compilers need checkcast when they use erasure; we're using a lot of
    erasure here, so we need the biggest checkcast we can get.  <br>
    <br>
    <blockquote type="cite" cite="mid:6367D637-CE41-4502-BD9B-3580FA5970DE@oracle.com">
      <div style="font-family: sans-serif;">
        <div class="markdown" style="white-space: normal;">
          <p dir="auto">Exactly where to put each |checkcast| (and where
            not to bother)<br>
            is an interesting question; perhaps it’s too much work to
            place<br>
            them on every read of a field. (I think it’s a good idea,
            because<br>
            redundant checks are free in the VM and earlier checks are
            better<br>
            than later ones.) But it seems very likely that at least
            field<br>
            writes will benefit from checkcasts, for all types that are<br>
            representable. And, note that type of <code style="margin:
              0; padding: 0 0.4em; border-radius: 3px; background-color:
              #F7F7F7;">new B3![]</code> is representable.<br>
            Its class will be <code style="margin: 0; padding: 0 0.4em;
              border-radius: 3px; background-color: #F7F7F7;">B3[].class</code>,
            but its representable type<br>
            will be something like <code style="margin: 0; padding: 0
              0.4em; border-radius: 3px; background-color: #F7F7F7;">NullRestrictedArray.of(B3.class)</code>.</p>
        </div>
      </div>
    </blockquote>
    <br>
    Spoiler: I much prefer to check on write, and ultimately, push that
    check into the VM using the same value set restriction machinery as
    we do for B3!.  <br>
    <br>
    <blockquote type="cite" cite="mid:6367D637-CE41-4502-BD9B-3580FA5970DE@oracle.com">
      <div style="font-family: sans-serif;">
        <div class="markdown" style="white-space: normal;">
          <p dir="auto">I don’t think there is a rift-healing move we
            could do with field<br>
            declarations, since flat |int| fields are already fully
            supported.</p>
        </div>
      </div>
    </blockquote>
    <br>
    We could be generous in linkage, treating "I" and "LInteger;" with a
    type restriction as the same type, but it doesn't seem worth it.  <br>
    <br>
    <blockquote type="cite" cite="mid:6367D637-CE41-4502-BD9B-3580FA5970DE@oracle.com">
      <div style="font-family: sans-serif;">
        <div class="markdown" style="white-space: normal;">
          <p dir="auto">Although it is technically an incompatibility,
            we might consider<br>
            allowing legacy |int[]| arrays to interoperate with
            |Object[]|,<br>
            so that more generic code can be written. That would be
            close to<br>
            the spirit of allowing |B3![]| arrays be viewed
            transparently as<br>
            possibly-null-tolerant |B3[]| arrays.</p>
        </div>
      </div>
    </blockquote>
    <br>
    I think we concluded that this was probably a forced move at some
    point, but we should revisit that analysis.  <br>
    <br>
    <blockquote type="cite" cite="mid:6367D637-CE41-4502-BD9B-3580FA5970DE@oracle.com">
      <div style="font-family: sans-serif;">
        <div class="markdown" style="white-space: normal;">
          <p dir="auto">(There is no cause to ask that |int|, which
            isn’t even a reference<br>
            type, should somehow be made to look like a subtype of
            |Integer|.)</p>
        </div>
      </div>
    </blockquote>
    <br>
    Yes, but its arrays may be a different story.  <br>
    <br>
    <blockquote type="cite" cite="mid:6367D637-CE41-4502-BD9B-3580FA5970DE@oracle.com">
      <div style="font-family: sans-serif;">
        <div class="markdown" style="white-space: normal;">
          <p dir="auto">I mean that the call |int.class.cast(x)| does
            not work, and lifting<br>
            that non-behavior up to |RepresentableType| will make a new
            and<br>
            unwelcome distinction between |B3!| and |int|: The mirror
            for |B3!|<br>
          </p>
        </div>
      </div>
    </blockquote>
    <br>
    (not actually a mirror)<br>
    <br>
    <br>
  </body>
</html>