Question about universal type variables

[Kevin Bourrillion]

On Wed, Jul 27, 2022 at 12:22 PM Brian Goetz <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 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.

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.


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

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.

Thanks!

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220727/3f451a2d/attachment.htm>