New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
implicit disaster: typetag reifies type param instead of type argument #5884
Comments
Imported From: https://issues.scala-lang.org/browse/SI-5884?orig=1 |
@paulp said: |
@xeno-by said (edited on Jun 5, 2012 5:13:18 PM UTC): But overall this typetag business is annoying. Especially since right now TypeTags are easy-to-type and referred by everyone involved, so they almost whisper to a newcomer "write me, write me, I'm simple and popular, come on". Your problem would have been solved if you used ConcreteTypeTags, though, but that's a mouthful, and who wants to type more. However we plan to address this problem by renaming TypeTag into AbsTypeable and ConcreteTypeTag into Typeable. Then TypeTag will become an odd one, which will nicely fit its surprising nature. |
@paulp said: Understand that I wasn't using anything. I changed a method from using typetags to classtags - or so I thought. (So I was trying NOT to use type tags.) The reason I use a typesafe language is so if I make a mistake like that, it will be caught by the compiler. It doesn't help to give it a different name. We have two things with similar, overlapping purposes, and if you put one where you mean the other, not only does everything still compile, but the manifestation of the problem is a million miles away. Really, a VerifyError in the scala.reflect package object which silently freezes startup and which only happens under select circumstances is not how I want to find out about what should be a static typing error. |
@paulp said: Do we not see that the audience for reifying unresolved type parameters is such a small fraction of the audience for reifying the actual explicit type argument that it is lost in the noise. To have a trap like this in place, in the default scope, on the basis that it's useful for that tiny audience... it is emblematic of the most common criticism of scala. |
@xeno-by said: |
@paulp said: |
@xeno-by said: |
@paulp said: If you leave it like this, just don't say later nobody saw it coming. |
@paulp said: scala> class Foo[T](implicit tag: TypeTag[T]) { def bippy = typeTag[T] }
defined class Foo
scala> (new Foo[List[Int]]).bippy
res0: TypeTag[List[Int]] = ConcreteTypeTag[List[Int]]
scala> class Foo2[T](implicit tag: TypeTag[T]) { def bippy = { val tag = "bippy" ; typeTag[T] } }
defined class Foo2
scala> (new Foo2[List[Int]]).bippy
res1: TypeTag[List[Int]] = TypeTag[T] |
@xeno-by said (edited on Jun 7, 2012 4:31:11 PM UTC): |
@paulp said: So does that mean my original example (and the one in the comment) will be compile time errors? |
@xeno-by said: Of course, if you replace all TypeTag[T] with AbsTypeTag[T] and typeTag[T] with implicitly[AbsTypeTag[T]], then you will observe the bug that you described. |
@paulp said: |
@xeno-by said: |
@paulp said: It isn't as if "Abs" is unambiguous, either. One can easily imagine an "absolute type tag" for instance, in contrast to a "relative" one which requires a prefix. An absent type tag, an absurd type tag... we have the means to alias long names. AbsTypeTag is still too long for me if I care about the length at all, so I'd have to alias it anyway. Why not let me alias from a name which doesn't require still more decoding. |
@xeno-by said: However, as of scala/scala@5acac4d the root cause of the problem is fixed, so I close this bug. |
I spent a good half a day trying to work out a VerifyError, which I eventually tracked back to this:
I sure hope it's intended to act like this:
The text was updated successfully, but these errors were encountered: