The storage hint model

[Maurizio Cimadamore]

On 21/07/2022 14:29, forax at univ-mlv.fr wrote:
> for me, using .flat or .box is a separate decision than using a storage hint model vs a type based model.

I'm not sure I'm sold.

Consider this:

```
class Box<X> {
   X x;
}
```

A question users will ask is: under which condition can I expect 
`Box<T>` to use flat representation for its `x` field ?

Now, in both cases the answer is - it depends, on both the type 
parameter T and what the declaration of `Box::x` looks like.

But if we adopt a .box approach, I think it will be hard for users not 
to read this as "T flowing into the Box implementation", because 
effectively that's what happens 99% of the times, except if you use the 
.box (or .ref) escape hatch. I other words, in a world where .flat is 
the default, and .box is the opt in, how is that world different from 
what you describe ".val propagation" ?

I think I know intuitively what you are reaching for - one thing is to 
treat .ref/.box as a type modifier (similar to a wildcard), another 
thing is to apply only to fields, and maybe array creation. But your 
example on ArrayList already veers into method parameters as well. At 
what point does it stop becoming a property of the container and starts 
being a property of the type? Not saying I have a bullet proof answer, 
but this all seems rather fluid to me.

Maurizio