Change classof

[odersky]

No description provided.

[DarkDimius]

tests/run/classof.scala: classOf[Array[Unit]]
failed in runtime:

[info] java.lang.IllegalArgumentException
[info]  at java.lang.reflect.Array.newArray(Native Method)
[info]  at java.lang.reflect.Array.newInstance(Array.java:75)
[info]  at scala.reflect.ClassManifestDeprecatedApis$class.arrayClass(ClassManifestDeprecatedApis.scala:91)
[info]  at scala.reflect.AnyValManifest.arrayClass(Manifest.scala:68)
[info]  at scala.reflect.ClassTag$class.wrap(ClassTag.scala:47)
[info]  at scala.reflect.AnyValManifest.wrap(Manifest.scala:68)
[info]  at dotty.DottyPredef$.arrayTag(DottyPredef.scala:12)
[info]  at Test$.main(classof.scala:34)
[info]  at Test.main(classof.scala)
[info]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[info]  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

[sjrd]

Turning classOf into a normal def with an implicit ClassTag is a tempting change, but it is has one major non-trivial consequence that needs that be thought through, at least: a tree for classOf[C] will not be a constant expression anymore!

This is particularly bad when it comes to annotations, as it won't be possible to use a classOf[C] in an annotation meant to be used by Java. This is very damaging for JUnit tests, for example, whose expect-exception-to-be-thrown tests are based on a classOf[SomeException] to be present in annotations.

[retronym]

I also would be reluctant to make classOf differ from Java's class literals. I've argued against such a change in Scalac.

[DarkDimius]

I agree that

classOf[T] is much nicer than implicitly[ClassTag[T]].runtimeClass.

I wouldn't be surprised if there will be some performance regressions if we follow the proposed scheme, as it would become harder for JVM to speculate\discover what particular java.lang.Class is being used. Now it would require to peeling of the ClassTag that wraps the java.lang.Class.

Though I agree that this potential inefficiency can be eliminated by a very simple optimization. And thus I propose to not consider the performance of runtime code when discussing this PR.

[odersky]

Yes, it's too bad. These are good arguments, unfortunatly ;-) I close the PR in favor of #1105.