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
Problem with implicit case classes #6227
Comments
Imported From: https://issues.scala-lang.org/browse/SI-6227?orig=1 |
@jsuereth said: object test {
def x(i: Int) = i
object x { def apply(i: Int) = i }
}
scala> test.x(1)
<console>:8: error: ambiguous reference to overloaded definition,
both object x in object test of type test.x.type
and method x in object test of type (i: Int)Int
match argument types (Int)
test.x(1)
^
|
@soc said: implicit case class Foo(val foo: Int)
Foo(1) This fails: <console>:10: error: ambiguous reference to overloaded definition,
both method Foo of type (foo: Int)Foo
and object Foo of type Foo.type
match argument types (Int)
Foo(1)
^ This is because the implicit class is desugared to an implicit method with the same name as the class, which makes the code ambiguous from the compiler POV. |
@odersky said: |
@odersky said: |
@Blaisorblade said (edited by @jsuereth on Aug 31, 2012 2:04:06 PM UTC):
|
@jsuereth said: Doing this destroys your ability to use name-binding to resolve implicit conflicts and import/remove implicits from scope. We initially wanted to do something like the above, but it turned out to be a bad idea overall. We also talked about having the implicit method be the Implicits are hard enough to reason through as is. We shouldn't add any surprises here unless we know we're improving the whole of it. |
@Blaisorblade said: |
@soc said: |
@Blaisorblade said (edited on Jul 27, 2013 4:37:19 PM UTC): object bip {
class Foo(val xxx: Int)
implicit object Foo extends (Int => Foo) { def apply(x: Int) = new Foo(x) }
} My colleague Tillmann Rendel came up again with this encoding. EDIT: So, why don't we use this desugaring? |
@retronym said: |
@Blaisorblade said (edited on Jul 31, 2013 2:21:24 PM UTC): And the obvious fixes require using a method instead of a companion object, at least for the implicit conversion (EDIT: which is the original encoding). I can imagine moving implicit def Foo = new {
def apply(x: Int) = new Foo(x)
def unapply(x: Foo) = ...
} but not only this doesn't work nowadays, I'm not even sure it is a good idea, since It seems that the only alternative is that the implicit conversion's name is derived in a documented way from the class name, either only for case classes (which preserves compatibility) or also for other classes (which ensures consistency). |
Implicit case classes are broken, because the type of the class and the type of the object are being mixed up:
The text was updated successfully, but these errors were encountered: