Remi,
IMHO, if you go down the storage modifier model, you have to let go of
the idea of annotating local parameters, and stick to fields and arrays
(e.g. "true" containers).
This means that some of the "sharp" info would be lost on the way, and
we would always use nullable representation on the stack.
It's a trade off, of course - the programming model has less types, we
lose ability for type information to flow from generic clients to
containers and we also lose some ability to fully flatten on the stack
(in the sense that a null side-channel will always need to be there,
e.g. in the form of another synthetic parameter).
Maurizio
On 27/07/2022 01:02, [email protected] wrote:
------------------------------------------------------------------------
*From: *"daniel smith" <[email protected]>
*To: *"Remi Forax" <[email protected]>
*Cc: *"valhalla-spec-experts" <[email protected]>
*Sent: *Wednesday, July 27, 2022 12:20:01 AM
*Subject: *Re: The storage hint model
On Jul 20, 2022, at 9:44 AM, Remi Forax <[email protected]> wrote:
And not having .ref and .val to be types greatly simplify the
model, because they is no interaction between the type
checking and the storage hints, those are two separated concerns.
To emphasize this point: I think we're talking about years of
development time that could be cut from this project if we could
live with storage modifiers rather than needing to thread the
flattening information through the type system. Not to mention the
downstream simplification for all the developers that don't have
to learn what a value type is.
(Think about it: no Q types, no .val/.ref, no boxing, no universal
generics, no new unchecked warnings, no secondary reflection
mirrors, no new descriptors, no bridges. Just a storage modifier
akin to 'volatile', support for that modifier in arrays, and value
classes able to opt in to allow that modifier.)
But there are details to sort out, and those details will
determine whether this simplifying move is a fantasy or a viable
alternative design.
No bridges but you still need the Preload attribute.
The main drawback is that the storage hints are not available when you
have an abstract method, so you have to fallback to the idea that any
type (type variables included) is nullable when calling a virtual
method (apart if the type has already been loaded). Maybe the cost can
be simulated by patching javac to never generates a Q-type (apart from
anewarray and fields) and generate a Preload attribute instead.
Rémi
