-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Change classof #1108
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
Change classof #1108
Conversation
Tests failures were caused by previous incomplete implementation of classTag.
Now diagnoses missing ClassTags of abstract types as implicit failures. Also: Simpler API of tpd.clsOf.
If a classtag for `T` is available, a classtag for `Array[T]` can also be generated.
Context bounds did not make it before into secondary constructors. Now the evidence parameters generated by context bounds get copied into secondary constructors. Without this fix, scala.collection.immutable.PagedSeq fails to compile in new classtag scheme.
Advantage: classOf is not magic anymore. It's also more flexible as it gives us an easy way to go from a ClassTag to a class. For the moment we leave the Classof phase in, in order to do the right thing if somebody references Predef.classOf explicitly (our improved classOf is in DottyPredef). Once we merge DottyPredef and Predef we can get rid of the phase.
Previously, the implicit definitions were always ambiguous, which is surely not right.
Tests that classOf as is discriminating than the previous definition in Scala (which was not implemented in dotty so far).
tests/run/classof.scala:
|
Cannot simply use `wrap` as it does the wrong thing for Array[Unit] (what a mess!).
Turning This is particularly bad when it comes to annotations, as it won't be possible to use a |
I also would be reluctant to make |
I agree that
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 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. |
Yes, it's too bad. These are good arguments, unfortunatly ;-) I close the PR in favor of #1105. |
No description provided.