Worse type inference when writing (x: Foo[_ >: A]) as opposed to [A1 >: A](x: Foo[A1])

[smarter]

In the following code, bar1 and bar2 are equivalent:

trait Foo[A] {
  def up[A1 >: A]: Foo[A1]
  def bar1(x: Foo[_ >: A]): Foo[A]
  def bar2[A1 >: A](x: Foo[A1]): Foo[A]
}

object Test {
  def test(a: Foo[Int], b: Foo[Any]) = {
    val x1 = a.up.bar1(b)
    val x2 = a.up.bar2(b)
  }
}

However, type inference works better for bar2 (in Dotty, both are inferred to Foo[Int]):

      val x1: Foo[Any] = a.up[Any].bar1(b);
      val x2: Foo[Int] = a.up[Int].bar2[Any](b);

It'd be good to figure out whether or not this can be fixed since this affects the API of the collections, in 2.13 we currently have in Seq:

def diff(that: Seq[_ >: A]): C

Which means that in the following code, x is inferred to have type Buffer[Any] and not Buffer[Int]:

object Test {
  def test(a: Seq[Int], b: Seq[Any]): Unit = {
    val x = a.toBuffer.diff(b)
  }
}

/cc @adriaanm @szeiger

[adriaanm]

Haven't looked closely, but does this conflict with #10819?

[smarter]

Don't think so, in both cases we should minimize the type variables because they appear in covariant or invariant positions

[adriaanm]

The problem that I was thinking of (maybe wrongly) was that we’d need to derive constraints only from type parameter bounds (and not from values). Let me take a closer look before commenting more randomly

…

On Wed, Nov 14, 2018 at 14:27 Guillaume Martres ***@***.***> wrote: Don't think so, in both cases we should minimize the type variables because they appear in covariant or invariant positions — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10920 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFjyx8fFb4F5Zd_WLHwzwSwu8vpq8qjks5uvBoqgaJpZM4UZNm3> .

[joroKr21]

Isn't the occurrence as a lower bound in contravariant position?

  def bar1(x: Foo[_ >: A]): Foo[A]

[smarter]

Yes, but it also appears in an invariant position (the A in Foo[A] in the result type), and the logic (at least in Dotty) is to consider that something that appears in positions with different variances as if it appeared in an invariant position.

[joroKr21]

Ok then at least we know where to look. scalac considers only the formal parameter types to compute the variance of type parameters:
https://github.com/scala/scala/blob/284a9c03c650c76e2b5295fee5c03565bcdf5246/src/compiler/scala/tools/nsc/typechecker/Infer.scala#L550

I tried adding the result type there but it caused breakage elsewhere.

[joroKr21]

There must be more to the story because this works fine:

scala> case class Fn[A, B](f: A => B)
// defined case class Fn

scala> Fn((s: String) => s.length)
val res0: Fn[String, Int] = Fn(rs$line$2$$$Lambda$1703/752060661@4207852d)

Although A appears in invariant position in the result type (Fn[A, B]) it is still inferred as String from the constraint A <: String which means A is maximized here.

[adriaanm]

Can we avoid the existential in the collections in favor of the type param? I think we're out of time to fix the typer for 2.13.

[szeiger]

Yes, this affects diff and intersect. Both had type parameters instead of existentials in 2.12, so there shouldn't be any unexpected side-effects when reverting to that state.

[szeiger]

Workaround in scala/scala#7630. Unassigning and rescheduling to 2.14.