Aggressive unboxing of values: status update

[Simon Ochsenreither]

> Note that the common idiom "a == b || a.equals(b)" is, practically speaking,
> a valid use of acmp for value boxes. If a or b is a heisenbox, "a == b" might
> always be false, causing a call to a.equals(b) which computes the intended
> boolean.

What about the other way around?
Instead of trying to figure out a way to add more or less non-sensical
implementations of ==/equals to value boxes, make them really thin wrappers
around value types, forwarding ==/equals to the value type's definition.
 
This is would very likely lead to an approach where we could say "within
specialized code, all value types (including primitives) have only one boxed
representation: the value box". (I think this would be vastly less complex than
e. g. having to deal with double, Double and box(double) in specialized code.)¹
 
This would only leave us with the question of what happens with value types in
non-specialized code, e. g. when you do "Object obj = someValueType": I think it
would be reasonable to have somewhat heavier "wrapper types" for value types
(like the current wrapper types for primitives), which would come with all the
baggage of object identity, being synchronizable etc.
 
Optionally, if a developer would require such a heavier representation within
specialized code, it would be possible to let him/her opt in with something like
<any T extends Object>, and disallow operations which would require such boxing
otherwise.
 
¹ I think having to deal with primitives, value boxes and wrapper types will
easily eat any available complexity budget.
 
WDYT?
 
Thanks,
 
Simon