Aggressive unboxing of values: status update

[Simon Ochsenreither]

Hi Victor!
 
As mentioned in an earlier email, it would certainly be desirable from a Scala
point of view to have a "clean" Top type.¹
 
The question just is how you deal with code, which just assumes that everything
is boxable (and has those methods)?
Even if T in "any T" could be made completely memberless, what would happen when
passing such a value type to a non-specialized T or assigning it to Object?
Or would it be necessary to specify that value types just can't be boxed in
non-specialized code (Object box, not value box)? That would probably make every
bit of written code incompatible with value types. :-/
 
¹ I think the reason why Scala devs are not really pushing for it is because in
Java it would require some approach to "re-add" those members (as you mentioned
in your mail), and in Java pretty much all you get are upper bounds. Imagine how
fun writing Java will be with an additional layer of upper bounds to many type
variables ... javac can hardly deal with the existing amount of Generics, and
I'd prefer not having to handle even more Generics coming from Java. So even if
Scala makes the Top type/T memberless, I think it will just do it as
"compiler-fiction", because the things required to implement the concept in Java
would be so terrible that it would negate the benefits. (Just my impression.)
 
(I'm very wary about the glorified #idefs proposed for deciding what method
exists in erased/specialized classes. (Deprecate the affected methods instead?))
 
Thanks and bye,
 
Simon