The storage hint model

[Robbe Pincket]

On Thu Jul 21 21:15:23 UTC 2022, Rémi wrote:

> Differences between C and C.val is really hard to understand because those types are really similar but obey to different rules
> - C and C.val have no subtyping relationship but if you see a type as a set, C accept null while C.val don't.
> - you have auto-boxing between a C and a C.val
> - overloading rules should prefer C.val to C (but maybe not)
> - the inference with C.val doe not work exactly like the inference with C
> - an array of C.val is a subtype of an array of C
> - List<C> and List<C.val> are incompatible types
> - instanceof C.val is not valid
> - c.getClass() with c a C.val is typed Class<? extends C> (not C.val).

I thought `c.getClass()` wasn't gonna be valid, just like you can't do `i.getClass()` where `i` is an int.

> and this is not an exhaustive list and I'm sure some of them are wrong because even us, experts, have trouble to define the correct set of rules.

> Basically, it's a mess because we are creating a new kind of types, C.val, that sometimes works like a primitive (hence boxing, overloading, type inference) but sometimes works like an objet (has Object as super class, have an adhoc way to work with wildcards, etc). And then as a user, there is there is the looming question about where to use C vs C.val, which is will be like a long words essay full of particular cases (like the Angelika Langer FAQ for generics).

I'm a bit confused here. `C.val` doesn't extend `Object` afaik. Just like primitives `C.val` has a boxed version `C` that does extend `Object`, much like `int` to `Integer` now.


I'm gonna be honest, I'm very confused with the `.box`/`.flat` discussions.

Greetings
Robbe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220721/3f60c3fa/attachment-0001.htm>