Imported From: https://issues.scala-lang.org/browse/SI-6668?orig=1
Reporter: @paulp

@retronym said (edited on Nov 14, 2012 9:31:16 PM UTC):
Members object p1.Test are, admittedly suprisingly, part of the implicit scope of A, as would be members of the package object p1. See #4427

@retronym said:
not-a-bugging for now.

@paulp said:
The other half of this is: can you tell me, is everyone on board with this situation where the ambiguous implicits in scope cancel one another out and it succeeds when it finds the companion scope implicit? That just violates every intuition I have about "good idea." It's like setting two wrongs equal to one right.

@harrah said:
My understanding is that this is a bug according to the specification independently of whether Test is part of the implicit scope of A (although I agree with Jason that it is) :

Implicit resolution first considers identifiers accessible without a prefix. It only moves on to the implicit scope (the companion object) if there are no eligible identifiers. If there are several eligible, overloading resolution applies. It does not appear to suggest that if that resolution is ambiguous, it continues to the implicit scope.

Caveat: I didn't bother to grab the latest specification, so mine might be out of date. I'll update it tomorrow.

@retronym said:

The actual arguments that are eligible to be passed to an implicit parameter of type T fall into two categories. First, eligible are all identifiers x that can be accessed at the point of the method call without a prefix and that denote an implicit definition (§7.1) or an implicit parameter. An eligible identifier may thus be a local name, or a member of an enclosing template, or it may be have been made accessible without a prefix through an import clause (§4.7). If there are no eligible identifiers under this rule, then, second, eligible are also all implicit members of some object that belongs to the implicit scope of the implicit parameter’s type, T .

The spec seems very wrong: it tells me that the presence of any implicit in scope, e.g. any of those I get from import Predef._, should inhibit the companion scope search.

The implementation looks like:

def inferImplicit(tree: Tree, pt: Type, reportAmbiguous: Boolean, isView: Boolean, context: Context, saveAmbiguousDivergent: Boolean, pos: Position): SearchResult = {
...
var result = searchImplicit(context.implicitss, true)

if (result == SearchFailure) {
  val previousErrs = context.flushAndReturnBuffer()

  result = materializeImplicit(pt)

  // `materializeImplicit` does some preprocessing for `pt`
  // is it only meant for manifests/tags or we need to do the same for `implicitsOfExpectedType`?
  if (result == SearchFailure) result = searchImplicit(implicitsOfExpectedType, false)

  if (result == SearchFailure) {
    context.updateBuffer(previousErrs)
  }
}
}

I'm going to seek a clerical interpretation on this one from Martin. At a minimum, the definition of "eligible" must be updated to "and conforms to the T". Then, we have to clarify what should happen when there is ambiguity. I'll track this under #6667.

@harrah said:
I agree "eligible" implies "conforms to T" and the spec should say that explicitly.

As a side note, the spec I have is actually the latest from the website, but the date on it is May 2011, so I thought there would be a more recent one.

@paulp said:
"I thought there would be a more recent one."

https://groups.google.com/d/msg/scala-language/E60_yrs_6lY/gE-jBH8tK0oJ