Question about universal type variables

[Remi Forax]

> From: "Kevin Bourrillion" <kevinb at google.com>
> To: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Wednesday, August 3, 2022 6:44:00 PM
> Subject: Re: Question about universal type variables

> On Thu, Jul 28, 2022 at 7:35 AM Brian Goetz < [ mailto:brian.goetz at oracle.com |
> brian.goetz at oracle.com ] > wrote:

>> On 7/27/2022 5:09 PM, Kevin Bourrillion wrote:

>>> On Wed, Jul 27, 2022 at 12:22 PM Brian Goetz < [ mailto:brian.goetz at oracle.com |
>>> brian.goetz at oracle.com ] > wrote:

>>>>> The main question of this email is: if T is a universal type variable, then what
>>>>> kind of type is that? Is it a reftype, a valtype, or something else?

>>>> It is a type of indeterminate ref-ness or val-ness.

>>> 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.

>> I wanted to recap the decisions that we've already made about *how* it works,

> Fine starting point, I was just trying to prompt the second step.

>> 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.)

>>> 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.

>> I don't think that type variables are actually a "kind" of type at all, in the
>> way you are thinking. In type theory,

> 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?

> 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.)

> Some "T always a reference type" advantages:

> * 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.

Here is an example where it's easy to see the difference between subtype polymorphism vs parametric polymorphism. 
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. 

It only works if T is bound by something that has not polymorphic methods, because obviously void has none. 
It can be Object but it can not be a reference otherwise null will be a possible value. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220803/e7ceee64/attachment-0001.htm>