<div dir="ltr">Okay, I have labored for way too long to try to discuss "are values objects?" without ever facing universal type variables head-on. Sorry! Here goes.<div><br></div><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><br></div><div>~~</div><div><br></div><div>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><div><br></div><div>I can see two main options for how to answer that, which I think follow naturally from the two <i>already</i>-existing models for how developers might conceptualize type variables.</div><div><br></div><div>These existing models, first:</div><div><br></div><div>Model 1: A type variable is a mere placeholder that "will be" some other type later. When you interact with it, you're "really" interacting with the future type argument. If asked a question like "is an `E` inside `class ArrayList<E>` a `Number`?" this model would say "well, it might be or it might not be".<br></div><div><br></div><div>Model 2: A type variable is a bona fide local type in its own right. It is or becomes no other type but itself. Its simple job is just to enforce whatever restrictions it needs to in order to <i>preserve its substitutability</i> for any type argument in-bounds. If asked the same question as above, "is an `E` inside `class ArrayList<E>` a `Number`?" this model would say "no, it is certainly not, but it does guarantee to be substitutable for `Number`, among other types."</div><div><br></div><div>I would describe Model 2 as being close to the JLS view of the world, but in a way, Model 1 is the very illusion that Model 2 is working to create. I certainly expect the majority of developers think like Model 1 most of the time, and most of the time it's okay.</div><div><br></div><div>~~</div><div><br></div><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><br></div><div>Model 2: All type variables are quite simply reftypes, because reftypes are the kind that are polymorphic. As always, a type variable will enforce whatever restrictions it must toward the goal of preserving its substitutability. Those restrictions are what make the type variable "universal" and produce the behaviors (quasi-nullness) we observe. Here, a value of type T is always a reference. Keep in mind that a generic class might eventually be used as a template to stamp out customized classes, and in <i>those</i> classes, your usages of T might be replaced with usages of some actual valtype. If asked "is an `E` inside `class ArrayList<E>` an `int`?" this model would answer, "not <i>per se</i>, but this same code might be used to stamp out a copy of ArrayList where `E` has been changed to `int`, so code with that in mind."</div><div><br></div><div><div>~~</div><div><br></div><div>I think Model 1 is close to how most developers think day-to-day, but maybe gets us into a bit of trouble sometimes. I think Model 2 is already the more accurate way to understand type variables, when an accurate understanding is needed, and we will probably base several of our JSpecify/nullness explanations on it (with care). People *will* still lean on Model 1 day-to-day, as now, but they'd do <i>best</i> to view it as a crutch when they do.</div><div><br></div><div>More to the point, maybe, I'd very, very much like to not wind up with three kinds of types, so, my money's on Model 2 at this point.</div><div><br></div><div>Interestingly, Model 2 drags the notion of a "non-nullable reference type" into the mix. And we'd like to keep a path open toward other kinds of NNRTs in the future, that act harmoniously with these. Uh oh! But... I think that sounds better than a future where NNRTs and universal-types both exist and are so similar.</div><div><br></div><div>I have no idea how any of this aligns or doesn't with the conversations that have already happened about UTPs.</div><div><br></div><div>Thoughts?</div><div><br></div><div>--<br></div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div></div></div>