The storage hint model

[John Rose]

On 21 Jul 2022, at 6:54, forax at univ-mlv.fr wrote:

> …
>>>> I've no idea about the performance of such kind of implementations, 
>>>> but >>> using
>>> T.flat give better control on what is flattenable or not in the 
>>> implementation.
>> If we choose, we can code this trick in the design of record as well.
>
> You mean in the design of array ? I don't think it's wise given that 
> the shape of the array change, but perhaps GCs can be modified to add 
> a relocate and unflat operation to array.

No, I mean in the design of ArrayList (or similar generics) in the way 
you sketch.  If we choose we can create shape-shifting List/Map/etc. 
containers which ignore the `.val` channel in their type args (or 
there’s none at all, as you are proposing here), accept nulls, but 
have a better internal organization if no nulls are encountered 
dynamically.

I say “if we choose” because there are reasons not to choose 
something that tricky and dynamic.  Library designers have more options 
if `.val` is in the type channel.

>
>> …If some but not all of those
>> locations accept my chosen SC, my refactorings have greater friction.
>
> If the variable is typed by a type variable, yes. But we have decided 
> to have the exact same kind of friction
> - with value class in practice because the VM is able to unmask the 
> value class on stack but not on heap.

Here by “friction” I think you mean hidden costs when heap placement 
of a value requires separate buffering of the payload also on heap.  
Alert users sometimes care about such subtleties.  But (here’s the key 
point) users who just want the types to connect things up properly can 
ignore hidden costs and have a frictionless experience refactoring 
between heap and stack.  That’s a win you don’t have when every user 
(alert or otherwise) is confronted with SC choices to align with type 
choices, during refactoring.

> - with wildcards (you have to add those pesky ? extends/super).

I have a separate proposal to patch that.  It’s irregular but (again) 
visible only to the very alert.  A plain value class name `C`, when it 
appears as a type argument, should be treated as sugar for `? extends 
C.ref`.  This is consistent, I claim, with the treatment of `C` as sugar 
for `C.ref` in other contexts.  It’s a little piece of the magic from 
Dan Smith’s thesis, applied specifically to the needs of type 
companions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220721/f529b0b5/attachment.htm>