Is there a reason why we make classOf fail, although we guarantee that all the necessary information is there, one line above?
--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Btw in C# both typeofs are mapped to a single bytecode instruction.
in fact, new Array[T] works if T has a tag available.
I argue it is exactly the same thing for classOf[T].
You argue incorrectly.
There's nothing stopping you from merging them somewhere, it's just that the somewhere isn't classOf.
There's a bunch of stuff that expects classOf to be statically resolved. The products of classOf are Constants with a capital C. You're not going to handle all the breakage which would arise from changing that, and I'm not volunteering. That's as much as I have to say.
By the way, was classOf ever made stable with regard to pattern matching (e.g., c match { case classOf[Int] => ... })?
I think a cleaner approach is to make `classOf` a macro. Paul got most of the way there in https://github.com/scala/scala/pull/1642.
You could omit the context bound and do a sneaky implicit search inside the macro for ClassTag[T] if the type parameter isn't a class type.
I'm still on the fence as to whether or not this is a good idea. I appreciate the utility but want us to make sure we think carefully about undesirable side effects.
One (somewhat contrived) example: we'll have to make sure that error messages for code like the following are still meaningful:class T[A: ClassTag] {@JavaAnnotation(classOf[A])}
--
I think a cleaner approach is to make `classOf` a macro. Paul got most of the way there in https://github.com/scala/scala/pull/1642.
--
I guess the issue is that we have now the context bound even in those cases we don't need it.
Recommendations? Revert to def classOf[T] = ... and check for the need and availability of a ClassTag in the compiler?
You might not like this answer, but my recommendation is to take a fresh look at the problem after the 2.11. This change doesn't have the right risk/reward nor cost/benefit profile for this release, IMO.
Thanks and bye,
Simon
--
1) I guess because it was a final val of a ConstantType.
3) Looks like a call to Predef.classOf slips through cracks and doesn't get transformed into a class reference.
--
What do you suggest?
--
Would it help to make classOf a whitebox macro?
t3222 seems to fail because partest needs to be recompiled and t4891 looks like some kind of weird crash while trying to report an error:
t3222 seems to fail because partest needs to be recompiled and t4891 looks like some kind of weird crash while trying to report an error:
scala> classOf[String]res0: Class[String] = class java.lang.Stringscala> class Foo[T : reflect.ClassTag] { def foo = classOf[T] }; new Foo[String].foodefined class Foores1: Class[_] = class java.lang.Stringscala> class Foo[T] { def foo = classOf[T] }; new Foo[String].foo<console>:8: error: No ClassTag available for Tclass Foo[T] { def foo = classOf[T] };;^
How did you solve the problems that you had before?
One thing I'm not perfectly happy about is the additional evidence parameter (which allows people to pass their own classtag evidence, imho not a good thing).
I'd prefer the way new Array[T] does it, but I haven't looked _how_ it's done for arrays yet. Any hints?
--
Here's how typer handles array instantiation: https://github.com/scala/scala/blob/master/src/compiler/scala/tools/nsc/typechecker/Typers.scala#L4468
But if you don't have any evidence in mkClassOf, then what are you going to select runtimeClass from?
EmptyTree if the result contains unresolved (i.e. not spliced) type parameters and abstract type members.