On 21 Jul 2022, at 6:54, [email protected] 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.
