<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><br></div><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><br></div><div>Your message continues with what purports to be justification for Model 1 over 2, I assume?, but it's only describing behavior (that is already understood from the JEP draft) that would behave the same way under either model. So I don't see what argument it's making. The behavior isn't in question, just the conceptual model.</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>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. </div></blockquote><div><br></div><div>Yes, of course. I don't even *expect* it to be an inherent property of a type that it necessarily knows how to conjure up instances of itself. After all, most of your examples don't work for a plain old abstract-class type either. Overall I'm not grasping what this is trying to argue about the question I've raised.</div></div><div><br></div><div>Thanks!</div><div><br></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>