type variable resolution contradicts language spec in a case of an inner class extending an outer class

[symingz]

Compiler version

3.4.2

Minimized code

class D[T]:
  class C[S] extends D[S]:
    def foo(x: T): T = x

@main def main(): Unit =
  val da = new D[String]
  val ea = new da.C[Int]
  println(ea.foo(10))

Output

-- [E007] Type Mismatch Error: Main.scala:8:17 ---------------------------------
8 |  println(ea.foo(10))
  |                 ^^
  |                 Found:    (10 : Int)
  |                 Required: String
  |
  | longer explanation available when compiling with `-explain`
1 error found

Expectation

The compiler's behavior is in fact reasonable, but it contradicts with Scala 3's language spec. In particular, in the chapter about types, a meta-function asSeemFrom is defined as follows:

We define asSeenFrom(T, C, p) where baseType(p, C) = q.C[U_1,...,U_n] as follows:

• If T is a reference to the ith class type parameter of some class D:
  • If baseType(p, D) = r.D[W_1,...,W_m] is defined, then W_i
  • ...
• ...

Applying this to the code above, to type check ea.foo(10), we compute asSeenFrom(foo(x: T):T, C, ea), which requires asSeenFrom(T, C, ea). T is a reference to the 1st type parameter of D. baseType(ea, D) = .D[Int], hence T =:= Int, and so ea.foo(10) should pass type check.

[som-snytt]

I expected ambiguity as with the s term; but I see that without U, it even takes the inherited s, perhaps because it is the same symbol.

trait U {
  def s = "hi"
}
class D[T] {
  val s = getClass.getName
  class C[S] extends D[S] with U {
    def foo(x: T): T = x
    override def toString = s
  }
}

[Gedochao]

cc @sjrd

[dwijnand]

Applying this to the code above, to type check ea.foo(10), we compute asSeenFrom(foo(x: T):T, C, ea), which requires asSeenFrom(T, C, ea). T is a reference to the 1st type parameter of D. baseType(ea, D) = .D[Int], hence T =:= Int, and so ea.foo(10) should pass type check.

I think your application of the spec is correct. To summarise the spec, the top branches are:

1. if T is a class D type param
2. if T is a this-type D.this
3. recursively apply to the components of T.

I'm not sure what the right spec change is, but initially I thought it might be adding a duplicate "if D is a subclass of C" precondition to that first baseType(p, D) = r.D[W_1,...,W_m] branch. But that makes the two branches even more suspiciously similar.

So I think the actual fix might be to just remove that first branch (1) about class type parameters, as I assume that how class type parameters are resolves on a prefix type is defined somewhere, and so it's just the resolution of the result of the recursive branch on type param reference. That is, if you recurse D.this.T, and for the prefix (D.this : D[T]) you get (da : D[String]), then your result is String.

If this is, also, where we define how type param references are resolve, then maybe we need to change the ordering somehow, so it's understood that the prefix is processed first.