<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Kevin Bourrillion" <kevinb@google.com><br><b>To: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>Cc: </b>"valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net><br><b>Sent: </b>Wednesday, August 3, 2022 6:44:00 PM<br><b>Subject: </b>Re: Question about universal type variables<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><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>
      
      <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>
                <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><br><div>Fine starting point, I was just trying to prompt the second step.</div><br><br><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>
      <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><br><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><br><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><br><div><b>Some "T always a reference type" advantages:</b></div><br><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.</div></div></div></div></blockquote><div><br></div><div>Here is an example where it's easy to see the difference between subtype polymorphism vs parametric polymorphism.<br data-mce-bogus="1"></div><div>At some point we will want T = void (or an unit type whatever it is exactly) so we can use the same functional interface for a function, a consumer or a producer.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>It only works if T is bound by something that has not polymorphic methods, because obviously void has none.<br data-mce-bogus="1"></div><div>It can be Object but it can not be a reference otherwise null will be a possible value.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>RĂ©mi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div></div></div></body></html>