Fix comparison of dependent function types

[odersky]

Dependent function types are expressed as refinements over regular function types.
These refinements need to be compared with the standard arrow rule for function
subtyping. But comparison of method refinements so far demanded equal parameter
types.

The solution is tricky since refined types lead to selections via reflection.
These still cannot tolerate differring parameter types since reflexive method dispatch
uses precise parameter types. That's why we apply the standard arrow rule only
for refinements where the refined method exists in the underlying class.

Fixes #12211

[smarter]

The solution is tricky since refined types lead to selections via reflection.
These still cannot tolerate differring parameter types since reflexive method dispatch
uses precise parameter types.

Note that even with the current restriction in places, structural selection via reflection is unsound in both Scala 2 and 3:

import scala.language.reflectiveCalls

class Sink[A] { def put(x: A): Unit = {} }

object Test {
  def main(args: Array[String]): Unit = {
    val a = new Sink[String]
    val b: { def put(x: String): Unit } = a
    b.put("") // NoSuchMethodException: Sink.put(java.lang.String)
  }
}

So I would be in favor of allowing variance in structural types by default and phasing out reflectiveCalls in some way since it's broken beyond repair anyway, except that it's apparenty a big deal for Scala.js and I don't know what to do there /cc @sjrd.

[odersky]

Can we fix reflexive dispatch to deal with the problem? We do have the restriction that refinements may not be overloaded. That should help.

[smarter]

We do have the restriction that refinements may not be overloaded. That should help.

Only sort of, even if there's no overloading in Sink in my example above, nothing prevents a subclass from adding an overload. We could try to pick a best-effort overload but even that is tricky and not cross-platform as discussed in scala/bug#12297.

[odersky]

If we assume the no-overload restriction, we could fix applyDynamic if we can pass an additionional Class parameter representing the static parent class of the function type.

I.e if there is only one method, pick that. If there are several, pick the one that is defined in the parent class, or that overrides a method defined in the parent class.

[smarter]

we could fix applyDynamic if we can pass an additionional Class parameter representing the static parent class of the function type.

I don't follow, by the time we're typing b.put("") all we know about b is that it has a method put, but we don't know in which class it's defined (if we did know, then we wouldn't need to emit a structural call).

[odersky]

@smarter You are right. So there would always be cases where a reflexive dispatch will be ambiguous.

[odersky]

The other alternative would be to be stricter, disallowing

val b: { def put(x: String): Unit } = a

[odersky]

We now have a deluxe version of refinement subtyping, where the signature check can be disabled by inheriting from
scala.Selectable.WithoutPreciseParameterTypes.

[smarter]

This needs to be @experimental or commented out until 3.1

[odersky]

I moved that part to a separate PR #12268 with a 3.1 milestone.

[odersky]

@smarter Ready to merge?

[smarter]

LGTM, I'd like to extend this to allow polymorphic functions to vary but I can try that in a separate PR.