Issue with Type inference?

[allanrenucci]

The following code snippet does not compile with Dotty but does with Scalac.

object Test {
  def second[A, B <: A](foo: A, bar: B): B = bar
  def expectString(s: String) = s

  def test = {
    second(Set.empty[String], Set.empty) map expectString
  }
}

It fails with the following error:

./tests/allan/Experiment.scala:7: error: type mismatch:
 found   : Any(s)
 required: String
    second(Set.empty[String], Set.empty) map expectString
                                             ^

It also fails to compile if second is defined as follow:

def second[A, B >: A](foo: A, bar: B): B = bar

with the following error:

./tests/allan/Experiment.scala:7: error: type mismatch:
 found   : (scala.collection.immutable.Set[String] | scala.collection.immutable.Set[Any]) @UnsafeNonvariant#A(s)
 required: String
    second(Set.empty[String], Set.empty) map expectString
                                             ^

Note that it does compile with second applied on List instead of Set:

second(List.empty[String], List.empty) map expectString

Not sure if it is a duplicate of #998

[odersky]

It might well be a duplicate of #998. Thanks for the analysis!

[odersky]

I verified that it is not a duplicate of #998, after all.

[allanrenucci]

#1040 did not completely fix the bug. If I rewrite slightly the test case, it doesn't compile anymore.

second(Set.empty[String], Set.empty) map (s => expectString(s))
third(Set.empty[String], Set.empty) map (s => expectString(s))

// Instead of
second(Set.empty[String], Set.empty) map expectString
third(Set.empty[String], Set.empty) map expectString

[odersky]

That looks like a bug / problem in scalac. scalac expands f to x => f(x) very early, before the checking
the rules of eta expansion. It then has to "assume" that x => f(x) was f in the user program. Dotty does eta expansion as part of adaptation, so it knows which is which.

In the scenario given, we need to infer the parameter type for s from the expected type. The expected type is not fully defined, so it gets approximated. And that leads to the error. If we write f instead of x => f x we can apply an additional rule, which says that if the expected type of an eta expansion is not fully defined we take the parameter type of f instead. But doing this for general expressions looks like a lot of trouble, and I'd like us to stay out of it.

[smarter]

But doing this for general expressions looks like a lot of trouble, and I'd like us to stay out of it.

Do you have a specific example in mind where this could be problematic? It doesn't seem like such a bad idea to me.