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
Artifacts from AnyVal getClass appear in signatures #4846
Comments
Imported From: https://issues.scala-lang.org/browse/SI-4846?orig=1 |
@paulp said: |
@soc said: scala> val list = List(1) ++ List('a') ++ List(1L)
list: List[AnyVal] = List(1, a, 1) Considering that getClass is already special-cased for AnyVals, would it be possible to at least clean up the REPL output? |
@ijuma said (edited on Jul 28, 2011 9:14:11 AM UTC): scala> List(1L) ++ List(1) ++ List(1L)
res4: List[AnyVal{def getClass(): java.lang.Class[_ >: Long with Int <: AnyVal]}] = List(1, 1, 1) Personally, I find this a bit odd. If you then call getClass on it, you get: scala> res4.getClass
res5: java.lang.Class[_ <: List[AnyVal{def getClass(): java.lang.Class[_ >: Long with Int <: AnyVal]}]] = class scala.collection.immutable.$colon$colon Personally, I think this should just return Class[_ <: List[AnyVal]], but I see what the compiler is doing. |
@SethTisue said: And with the Scaladoc stuff removed, having the ticket assigned to "Scaladoc Team" no longer makes sense, so I'm changing the status of the ticket to "Invalid", since Paul said "The inferred type is correct." The inferred type may be "correct" in some sense, but it certainly doesn't seem like the best type to be inferred here. Is this really how it must be? If it stays this way I think this is going to get noticed pretty frequently — especially by beginners. I'll take it up on the mailing list. |
@SethTisue said:
|
@paulp said: Welcome to Scala version 2.8.1.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_26). scala> List(1L: java.lang.Long) ++ List(1: java.lang.Integer) |
@SethTisue said: So, reopening the ticket but reclassifying it as an enhancement. Martin's suggestion wouldn't help the java.lang.Long/Integer case Paul noticed, but oh well. |
@SethTisue said: |
Commit Message Bot (anonymous) said: "Fiddle with lubs and glbs by never considering getClass as a member in Closes #4846. |
@SethTisue said: |
In 2.9.0.1:
In 2.9.1RC1/2.10-trunk:
I'm not sure if this is a bug or an enhancement.
Imho the type signature is exposing some implementation detail of getCLass for AnyVals (probably related to #864) and shouldn't appear anywhere.
I really don't want to explain that type signature to a beginner ...
The text was updated successfully, but these errors were encountered: