Scala implicit def do not work if the def name is toString

  • A+
Category:Languages

This code fails to compile:

object Foo {   implicit def toString(i: Int): String = i.toString         def foo(x: String) = println(x)   foo(23) }     

Above code fails to compile with following error:

error: type mismatch; found   : scala.this.Int(23) required: String   foo(23) 

But, this code compiles

object Foo {   implicit def asString(i: Int): String = i.toString         def foo(x: String) = println(x)   foo(23) } 

Why does the name of an implicit def should matter?

Note: If the method is named equals, it also does not work but it works if it is named hashCode or clone etc.

 


The problem here isn't that toString is overloaded on Foo, as one of the other (now-deleted) answers argues (you can try overloading asString similarly and it'll work), it's that the toString you're importing collides with the toString of the enclosing class (in your case some synthetic object made up by the REPL).

I think the following implicit-free examples (which also don't use "built-in" method names like toString) show the issue a little more clearly:

class Foo {   def asString(i: Int): String = "this is the one from Foo!" }  class Bar {   def asString(i: Int): String = "this is the one from Bar!" }  object Demo extends Bar {   val instance = new Foo   import instance._    println(asString(23)) } 

This will use the asString from Bar, even though you might think the imported one would take precedence:

scala> Demo this is the one from Bar! res1: Demo.type = Demo$@6987a133 

In fact it'll use the definition from Bar even if the arguments don't line up:

class Foo {   def asString(i: Int): String = "this is the one from Foo!" }  class Bar {   def asString(): String = "this is the one from Bar!" }  object Demo extends Bar {   val instance = new Foo   import instance._    println(asString(23)) } 

This fails to compile:

<pastie>:25: error: no arguments allowed for nullary method asString: ()String   println(asString(324))                    ^ 

Now we can make this look more like your original code:

class Foo {   implicit def asString(i: Int): String = "this is the one from Foo!"   def foo(s: String): String = s }  class Bar {   def asString(): String = "this is the one from Bar!" }  object Demo extends Bar {   val instance = new Foo   import instance._    println(foo(23)) } 

This fails with the same error you saw, for the same reason: the imported implicit conversion is hidden by the definition with the same name in the enclosing class.

Footnote 1

You asked the following:

Why does the name of an implicit def should matter?

Names of implicits matter all the time. That's just the way the language works. For example:

scala> List(1, 2, 3) + "" res0: String = List(1, 2, 3)  scala> trait Garbage defined trait Garbage  scala> implicit val any2stringadd: Garbage = new Garbage {} any2stringadd: Garbage = $anon$1@5b000fe6  scala> List(1, 2, 3) + "" <console>:13: error: value + is not a member of List[Int]        List(1, 2, 3) + ""                      ^ 

What we've done is defined an implicit value that hides the any2stringadd implicit conversion in scala.Predef. (Yes, this is kind of terrifying.)

Footnote 2

I think there's probably a compiler bug here, at least as far as the error message is concerned. If you change things up just a little bit in my second version above, for example:

class Foo {   def asString(i: Int): String = "this is the one from Foo!" }  class Bar {   def asString(): String = "this is the one from Bar!" }  object Demo extends Bar {   def test(): Unit = {     val instance = new Foo     import instance._      println(asString(23))   } } 

…you get a much more reasonable message:

<pastie>:26: error: reference to asString is ambiguous; it is both defined in class Bar and imported subsequently by import instance._     println(asString(23))             ^ 

In my view this is almost certainly the kind of thing the compiler should tell you in your original case. I'm also not sure why the hidden implicit is considered for the conversion at all, but it is, as you can tell if you run your code in a REPL with -Xlog-implicits:

scala> foo(23) <console>:16: toString is not a valid implicit value for Int(23) => String because: no arguments allowed for nullary method toString: ()String        foo(23)            ^ 

So it looks like the implicitness is rubbing off on the other toString? To be honest I have no idea what's happening here, but I'm like 90% sure it's a mistake.

Comment

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: