I think we're kind of stuck with a model like this, whether we admit it
or not, because we have to allow for pervasive erasure and be able to
fall back to looser linkage conventions. SO the type restriction was
always optimistic; we might say "Object restricted to QPoint", but
someone could show up and say "what's a restriction?" and then we have
to respond "I said Object, sir".
On 1/28/2022 1:00 PM, Dan Smith wrote:
But I think we can hold on to this property and still support disjoint
Q/L. How? By not allowing type restrictions to literally claim that
values have Q types. Instead, they claim that a value with some L type
is *freely convertible to* a particular Q type. (This may be the same
thing as John saying the type restriction involves projections and
embeddings, although I'm not sure I would make it the type
restriction's responsibility to encapsulate those conversions.)
So, for example: a type restriction that we might spell as 'QPoint'
(and maybe that notation is a mistake) is an assertion that a
particular L-typed variable always stores non-null objects for which
'instanceof Point' is true. *But they're still objects*, as far as the
abstract JVM is concerned. Then the JVM implementation is free to
recognize that it can use the same encoding it uses for the actual
type 'QPoint' to store things in the variable.
There are a couple places where reality intrudes on this simple model:
- The initial value of a field/array with a type restriction is
determined by that type restriction (because, e.g., 'null' can't
satisfy the 'QPoint' restriction)
- Type restrictions may introduce tearing risks, which would have to
be explained by specifying the possibility that a JVM implementation
may use type restrictions to optimize storage of value object
instances of primitive classes, encoding them as primitive values
I'm left feeling somewhat uneasy that we end up with a world in which
directly-typed code has Q types, while specialized generic code has
<non-null instances of primitive classes> as its "types"—two different
ways to explain the exact same thing, in some sense duplicating
efforts—but I think we can live with that. On the other hand, it's a
nice win that the language runtime model is more closely aligned with
the JVM's runtime model (where value objects and primitive values are
two distinct things).
