Hello,
I have some code that passes javaClass<Int>(), javaClass<Float>() and so on for other primitive types. The receiving side correctly gets the Java primitive classes (i.e. int.class, float.class, etc). With Kotlin M10, I tried to convert that code to inline+reified but I’m getting the corresponding box classes (Integer.class, Float.class, etc). Is this an known limitation/issue?
This is a known limitation. I don't think there's any way the compiler could guess which one you mean: the wrapper or the primitive. If you have any ideas thereof, I"m glad to discuss them
My first thought was to abuse Int vs Int?, but that changes semantics and you're probably not using T just for javaClass<T>().
Next would be an argument on reified, but it’s a (soft) keyword, not an annotation. So, it could be an argument on inline.
The default would be how it works now. An argument would change the reification to use primitive classes. Note that since this happens on the declaration side rather than on use, it would make the reification work with either primitive or wrapper classes, not both. Imho this is acceptable, if you need primitive classes you’re probably doing something applicable to primitives only.
We could make it a parameter to reified (it will become an annotation one day), but this being strictly JVM-specific doesn't sound like a very clean concept...
Isn't reified JVM-specific anyway?
Btw, an update on class specialization is available, here. It looks like that Kotlin will have the same issue with primitive specialization. Could a solution be to allow int, long, float (vs Int, Long, Float) on type parameters?
There's nothing platform-specific in the concept of reified as it stands now.
When Valhalla gets a little more in shape, we will investigate the consequences, but for now it doesn’t seen to add more trouble