<div dir="ltr"><div dir="ltr">On Thu, Jul 28, 2022 at 7:35 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>> wrote:</div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div>On 7/27/2022 5:09 PM, Kevin Bourrillion
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">On Wed, Jul 27, 2022 at 12:22 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>>
wrote:</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<blockquote type="cite">
<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>
It is a type of indeterminate ref-ness or val-ness.</div>
</blockquote>
<div><br>
</div>
<div>This is to merely assert that Model 1 is correct. But I
was asking for a fair consideration of both models and a
discussion of *why* one is better than the other. It's not
clear whether that was understood.</div>
</div>
</div>
</blockquote>
I wanted to recap the decisions that we've already made about *how*
it works, </div></blockquote><div><br></div><div>Fine starting point, I was just trying to prompt the second step.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>before stepping onto the philosophical playing field. Its
not something we've discussed a lot, and wanted to make sure there
were no misconceptions about how works. (For example, it's easy to
assume that "of course" things like `new T[3]` and `new T(foo)`
might work under specialization, though these are fairly
presumptuous assumptions.) <br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>I think this is worth some serious consideration, because
having to say that there are three kinds of types now in
Java would be quite disappointing.</div>
</div>
</div>
</blockquote>
<br>
I don't think that type variables are actually a "kind" of type at
all, in the way you are thinking. In type theory, </div></blockquote><div><br></div><div><div>I'm sure the theoretic argument is fine as far as it goes, but it's not much help for the end user. My issue is with the user model we present to the world; what "useful fictions" are we securing for them, that enable them to read and write code with confidence?</div><div><br></div><div>I'm sure the notion that T is always a reference type would be initially surprising to many; maybe enough so that that makes it the wrong model. But I wanted to (re)state some advantages I see in it. (If some are built on misunderstandings, I'm hoping to shake those out.)</div><div><br></div><div><b>Some "T always a reference type" advantages:</b></div><div><br></div><div>* With subtype polymorphism, the user enjoys a solid understanding that "reference types are polymorphic, value types are monomorphic". As I'd put it: you can never have a value (say as a field) without statically knowing its exact type, because its exact type governs the shape and interpretation of the bits actually making up the value. Don't know the exact type --> you need a reference. But parametric polymorphism (thanks for laying out these terms in the JEP draft, Dan) feels very similar! I'd expect the user to consult the same intuitions we just drilled into them about subtype polymorphism. It would be nice if the same simple rule held there too.<br></div><div><br></div><div><div><div>* When my class gets used as `MyClass<int>`, I would get to reason like so:<br></div></div></div><div> * When that code runs on some JVM that doesn't do specialization yet, then my class gets used directly, so those `int`s are really `Integer`s; of course they are, because T is a reference type. (I expect I can't tear a value this way.)</div><div> * When that code runs on some JVM that has specialization, then different "species" of my class are being forked off from my template, each one physically <i>replacing</i> T with some value type. So <i>those</i> are value types, but once again T is still a reference type. (And here I do expect tearing risk, for non-atomic types.)</div><div><div><br></div></div><div>* If Java might ever to have non-nullable reference types, I suspect it might immediately expose this whole type variable issue as having been, at its essence, never really about ref-vs-val in the first place. What it's really about is that there used to be one value in the intersection of every Object type's value set, and now there isn't anymore.</div><div><br></div><div>* The best way a user can prepare their generic class for becoming "universal" in the future is to adopt aftermarket nullness analysis (such as I'm working on standardizing the semantics for in JSpecify). They'll mark type parameters like `V extends @Nullable Object`, and methods like `Map.get` will return `@Nullable V`. That will shake out any obstacles up front. Then once V becomes a UTP, they'd just change that `V` to `V.ref`, and they could presumably drop the `@Nullable` too because `.ref` implies it (why else would it be used?). So the language feature you're introducing for ref-vs-val universality is immediately doing double duty, capturing nullness information for reference types too.</div><div><br></div><div>This would probably mean rethinking the `T.ref` syntax to something that more closely evokes "T or null" (the fact this would, for an <int> species, have to box to `Integer` in the process seems intuitive enough).</div></div><div><br></div></div>-- <br><div dir="ltr"><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>