Take implicit parameters into account for is-as-specific computations

[odersky]

Number of implicit parameters is applied as a final tie break, if
two alternatives would be otherwise equally specific.

I tried to roll them into type specificity first, but this fails
the dotc bootstrap where we have:

 def name(implicit ctx: Context): Name  in class Denotation

 val name: Name                         in subclass SymDenotation

The val name wins, since it is defined in a subclass and the result types
are the same. If we let the type (implicit ctx: Context): Name win over
Name this would be ambiguous instead.

[odersky]

Based on #5887. First new commit is 4d6b82e.

[milessabin]

@odersky take a look at the logic I used here to deal with the specificity problem you mention in the description above ... search for nullaryImplicitArgs.

[odersky]

@milessabin Yes, that's what I implemented first. But it runs afoul of the problem I mentioned. The difference between the approaches is that I now use implicit parameters only as a final tie breaker, after both type specificity and location are taken into account.

[milessabin]

@odersky If I can make it work for that case would you be open to going in that direction?

[odersky]

@odersky If I can make it work for that case would you be open to going in that direction?

Possibly, but I quite like the simplicity of the current solution (both implementation and spec-wise). What would we gain by changing it?

[odersky]

Here's the current text:

1. The rule for picking a most specific alternative among a set of overloaded or implicit
   alternatives is refined to take the number of inferable parameters into account. All else
   being equal, an alternative that takes more inferable parameters is taken to be more specific
   than an alternative that takes fewer. The following paragraph in the SLS is affected by this change:

   Original version:

   An alternative A is more specific than an alternative B if the relative weight of A over B is greater than the relative weight of B over A.

   Modified version:

   An alternative A is more specific than an alternative B if

   • the relative weight of A over B is greater than the relative weight of B over A, or
   • the relative weights are the same and A takes more inferable parameters than B.

[milessabin]

What would we gain by changing it?

Without it we miss out on things like this (from the Scala 2 PR),

class Low
object Low {
  implicit val low: Low = new Low
}
class Medium extends Low
object Medium {
  implicit val medium: Medium = new Medium
}
class High extends Medium
object High {
  implicit val high: High = new High
}

class Foo[T](val i: Int)
object Foo {
  def apply[T](implicit fooT: Foo[T]): Int = fooT.i

  implicit def foo[T](implicit priority: Low): Foo[T] = new Foo[T](0)
  implicit def foobar[T](implicit priority: Low): Foo[Bar[T]] = new Foo[Bar[T]](1)
  implicit def foobarbaz(implicit priority: Low): Foo[Bar[Baz]] = new Foo[Bar[Baz]](2)
}
class Bar[T]
object Bar {
  implicit def foobar[T](implicit priority: Medium): Foo[Bar[T]] = new Foo[Bar[T]](3)
  implicit def foobarbaz(implicit priority: Medium): Foo[Bar[Baz]] = new Foo[Bar[Baz]](4)
}
class Baz
object Baz {
  implicit def baz(implicit priority: High): Foo[Bar[Baz]] = new Foo[Bar[Baz]](5)
}

object Test extends App {
  assert(Foo[Int] == 0)
  assert(Foo[Bar[Int]] == 3)
  assert(Foo[Bar[Baz]] == 5)
}

[odersky]

OK, I see now. We need not just the number but also the types of the implicit parameters to influence priority. We could probably do this also as a final tie break, however.

I like to push these tie breaks back in the sequence of decisions not just for backwards compatibility but also for complexity. Overloading comparisons can be a significant part of compile-time (I believe for ScalaTest ~20%) and they can explode combinatorically. The current implementation tries very hard to minimize the number of specificity comparisons for types. If we do more complex checks only as a last resort when we would report an ambiguity otherwise, we know that they will be called only rarely.

[odersky]

A modified^2 version could be:

1. An alternative A is more specific than an alternative B if

   • the relative weight of A over B is greater than the relative weight of B over A, or
   • the relative weights are the same and A takes more inferable parameters than B, or
   • the relative weights and the number of inferable parameters are the same and
     A is more specific than B if all inferable parameters in either alternative are replaced by regular parameters.

Would that work?

[milessabin]

Where "relative weight" is the specificity of the result type? Yes, I think that works :-)

[odersky]

Where "relative weight" is the specificity of the result type? Yes, I think that works :-)

Relative weight is the outcome of the combined specificity / ownership test. You get one weight point for "as specific as" and one weight point for "owned by a subclass (or its companion object)".

[odersky]

@milessabin The changed spec is in
docs/docs/reference/changed-features/implicit-resolution.md

Can you take a look whether we can leave it like this?

[milessabin]

This is absolutely spot on ... it's a huge improvement over Scala 2 and addresses pretty much all of my issues :-)