> 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 < [ mailto:[email protected] | >> [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
