Scala: Implicit parameter resolution precedence

Question

Suppose we have implicit parameter lookup concerning only local scopes:

trait CanFoo[A] {
  def foos(x: A): String
}

object Def {
  implicit object ImportIntFoo extends CanFoo[Int] {
    def foos(x: Int) = "ImportIntFoo:" + x.toString
  }
}

object Main {
  def test(): String = {
    implicit object LocalIntFoo extends CanFoo[Int] {
      def foos(x: Int) = "LocalIntFoo:" + x.toString
    }
    import Def._

    foo(1)
  }

  def foo[A:CanFoo](x: A): String = implicitly[CanFoo[A]].foos(x)
}

In the above code, LocalIntFoo wins over ImportedIntFoo. Could someone explain how it's considered more specific using "the rules of static overloading resolution (§6.26.3)"?

Edit:

The name binding precedence is a compelling argument, but there are several issues unresolved. First, Scala Language Reference says:

If there are several eligible arguments which match the implicit parameter’s type, a most specific one will be chosen using the rules of static overloading resolution (§6.26.3).

Second, name binding precedence is about resolving a known identifier x to a particular member pkg.A.B.x in case there are several variable/method/object named x in the scope. ImportIntFoo and LocalIntFoo are not named the same.

Third, I can show that name binding precedence alone is not in play as follows:

trait CanFoo[A] {
  def foos(x: A): String
}

object Def {
  implicit object ImportIntFoo extends CanFoo[Int] {
    def foos(x: Int) = "ImportIntFoo:" + x.toString
  }
}

object Main {
  def test(): String = {
    implicit object LocalAnyFoo extends CanFoo[Any] {
      def foos(x: Any) = "LocalAnyFoo:" + x.toString
    }

    // implicit object LocalIntFoo extends CanFoo[Int] {
    //   def foos(x: Int) = "LocalIntFoo:" + x.toString
    // }
    import Def._

    foo(1)
  }

  def foo[A:CanFoo](x: A): String = implicitly[CanFoo[A]].foos(x)
}

println(Main.test)

Put this in test.scala and run scala test.scala, and it prints out ImportIntFoo:1. This is because static overloading resolution (§6.26.3) says more specific type wins. If we are pretending that all eligible implicit values are named the same, LocalAnyFoo should have masked ImportIntFoo.

Related:

• Where does Scala look for implicits?

This is a great summary of implicit parameter resolution, but it quotes Josh's nescala presentation instead of the spec. His talk is what motivated me to look into this.

Compiler Implementation

• rankImplicits

Answer 1

I wrote my own answer in the form of a blog post revisiting implicits without import tax.

Update: Furthermore, the comments from Martin Odersky in the above post revealed that the Scala 2.9.1's behavior of LocalIntFoo winning over ImportedIntFoo is in fact a bug. See implicit parameter precedence again.

• 1) implicits visible to current invocation scope via local declaration, imports, outer scope, inheritance, package object that are accessible without prefix.
• 2) implicit scope, which contains all sort of companion objects and package object that bear some relation to the implicit's type which we search for (i.e. package object of the type, companion object of the type itself, of its type constructor if any, of its parameters if any, and also of its supertype and supertraits).

If at either stage we find more than one implicit, static overloading rule is used to resolve it.

Update 2: When I asked Josh about Implicits without Import Tax, he explained to me that he was referring to name binding rules for implicits that are named exactly the same.

Answer 2

From http://www.scala-lang.org/docu/files/ScalaReference.pdf, Chapter 2:

Names in Scala identify types, values, methods, and classes which are collectively called entities. Names are introduced by local definitions and declarations (§4), inheritance (§5.1.3), import clauses (§4.7), or package clauses (§9.2) which are collectively called bindings.

Bindings of different kinds have a precedence defined on them: 1. Definitions and declarations that are local, inherited, or made available by a package clause in the same compilation unit where the definition occurs have highest precedence. 2. Explicit imports have next highest precedence. 3. Wildcard imports have next highest precedence. 4. Definitions made available by a package clause not in the compilation unit where the definition occurs have lowest precedence.

I may be mistaken, but the call to foo(1) is in the same compilation unit as LocalIntFoo, resulting in that conversion taking precedence over ImportedIntFoo.