On 21/07/2022 14:29, [email protected] 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
