<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>