<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<br>
<blockquote type="cite" cite="mid:CAGKkBksfTUPwGmKM6dQLVKVm_GTvibshLVJBr9KpKTME9LRdxg@mail.gmail.com">
<div dir="ltr">
<div>My (limited) understanding is:</div>
<div><br>
</div>
<div>a) The first goal is just to enable a type parameter to
accept both reftypes and valtypes as type arguments (making it
a "universal" type parameter or UTP, and making the type
variable it defines for use inside that scope a UTV).</div>
<div><br>
</div>
<div>b) Goals to follow would do progressively more efficient
things when the type arguments are valtypes. I'd expect that
optimal performance demands dynamically generating customized
versions of the class in some manner (which I'd further expect
is fair to call "templating"?).</div>
<div><br>
</div>
<div>For starters, does the above seem accurate and well-stated?</div>
</div>
</blockquote>
<br>
Correct. We envision two phases, like your (a) and (b), where the
first is an erasure-based, language-based system which conforms to
the behavior that the VM-based specialization would offer, allowing
specialization to be viewed as a pure optimization, rather than an
actual language feature. <br>
<br>
<blockquote type="cite" cite="mid:CAGKkBksfTUPwGmKM6dQLVKVm_GTvibshLVJBr9KpKTME9LRdxg@mail.gmail.com">
<div dir="ltr">The main question of this email is: if T is a
universal type variable, then <i>what kind of type</i> is that?
Is it a reftype, a valtype, or something else?</div>
</blockquote>
<br>
It is a type of indeterminate ref-ness or val-ness. This will have
both restrict some old behavior and provide some new behavior. For
example:<br>
<br>
T t = null;<br>
<br>
will generate an unchecked warning, since we can't be sure we're not
polluting the heap with nulls. (Null pollution is a straightforward
special case of heap pollution.) On the other hand, you'll be able
to use the new derived type `T.ref`, which would mean "T if its
already a ref, or the ref companion if T is a val." This allows
Map::get to be rescued:<br>
<br>
V.ref get(K k);<br>
<br>
<blockquote type="cite" cite="mid:CAGKkBksfTUPwGmKM6dQLVKVm_GTvibshLVJBr9KpKTME9LRdxg@mail.gmail.com">
<div dir="ltr">
<div>If we follow these models where they lead they seem to
suggest two different answers for my question (i.e.,"if T is a
UTV, what kind of type is that?"):</div>
<div><br>
</div>
<div>Model 1: Since the UTV type represents or "stands in for"
future type arguments which might be of either kind -- and
note that it does behave differently from any regular reftype
or valtype, being sort of quasi-nullable -- we are forced to
conclude that it will be a third kind of type, a "universal"
type. So the Java type system ends up tripartite after all.
And, what is a value of this type?</div>
<div> * The values-are-not-objects model stammers, "you've got
a class instance for sure, but it might ambiguously be a value
or a reference to an object, and often that doesn't matter".<br>
</div>
<div> * The values-are-objects model stammers, "you've got an
object for sure, all you don't know is the 'placement' of the
object, direct or indirected, and often that doesn't matter".</div>
</div>
</blockquote>
<br>
So, note that in a generic class today, there's no way to "summon"
any value of T *except null*. You can't say `new T()` or `new T[3]`
or `T.class.newInstance()`. The values of T (except null) always
come from *outside the house*, and their T-ness is backed up by
synthetic casts (modulo heap pollution). An ArrayList<T>
starts out empty, then someone puts T's in it, at which point the
ArrayList can turn around and hand those Ts back. But it can't make
any new Ts. All it needs to know is that T is layout-compatible
with the layout of the bound. <br>
<br>
<br>
</body>
</html>