type resolution with path-dependent types fails (works in Scala 2)

[yurique]

Compiler version

3.3.4, 3.6.2

Minimized code

trait Module {
  trait Reader[T]
}

class Builder[M <: Module](val m: M) {

  def json[Receive](implicit
                    reader: m.Reader[Receive], // path-dependent type here
                   ): Unit = {}

}

object mod extends Module

object Main {

  implicit val stringReader: mod.Reader[String] = new mod.Reader[String] {}

  def builder[M <: Module](m: M): Builder[M] = new Builder[M](m)

  def main(args: Array[String]): Unit = {
    builder(mod).json[String](stringReader) // the expected type of the reader parameter is Nothing  
   
  }

}

Output

$ scala-cli --scala 3.6.2 test.sc
Compiling project (Scala 3.6.2, JVM (17))
[error] ./test.sc:22:31
[error] Found:    (test$_.Main.stringReader : test$_.this.mod.Reader[String])
[error] Required: Nothing
[error]     builder(mod).json[String](stringReader) // the expected type of the reader parameter is Nothing
[error]                               ^^^^^^^^^^^^
Error compiling project (Scala 3.6.2, JVM (17))
Compilation failed

$ scala-cli --scala 2.13.15 test.sc
Compiling project (Scala 2.13.15, JVM (17))
Compiled project (Scala 2.13.15, JVM (17))

Expectation

I was expecting this to compile in Scala 3, since it compiles and works in Scala 2.13.
But I don't know if this is supposed to work, or if I'm doing it wrong, or if there is a workaround.

[KacperFKorban]

This would be a workaround. i.e. Adding a type parameter with an upper bound.

//> using scala 3.nightly

trait Module {
  trait Reader[T]
}

class Builder[M <: Module](val m: M) {
  def json[Receive, R <: m.Reader[Receive]](using reader: R): Unit = {}
}

object mod extends Module

given stringReader: mod.Reader[String] = new mod.Reader[String] {}

def main(args: Array[String]): Unit = {
  new Builder(mod).json(using stringReader) // the expected type of the reader parameter is Nothing  
}

[yurique]

@KacperFKorban thank you for the suggestion!

The problem with this is I'll have to add that extra type parameter (R) and it will make it hard to use.

The real code where I encountered this has two type parameters, so it's even worse: https://github.com/tulz-app/laminext/blob/series/0.16.x/modules/websocket-upickle/src/main/scala/io/laminext/websocket/upickle/WebSocketReceiveBuilderUpickleOps.scala#L12

The usage would have to change from

val ws = 
  WebSocket
    .url("wss://echo.websocket.events")
    .upickle(OptionPickler)
    .json[DataToSend, DataToReceive]
    .build()

to

val ws = 
  WebSocket
    .url("wss://echo.websocket.events")
    .upickle(OptionPickler)
    .json[DataToSend, DataToReceive, OptionPickler.Reader[DataToSend], OptionPickler.Writer[DataToReceive]]
    .build()

which is far from perfect :)

[noti0na1]

investigating more cases:

trait Module:
  trait Reader[T]

class Builder[M <: Module](val m: M):
  def json[Receive](reader: m.Reader[Receive]): Unit = {}

object Test:

  object mod extends Module

  val stringReader: mod.Reader[String] = new mod.Reader[String] {}

  val mod2 = new Module {}

  val stringReader2: mod2.Reader[String] = new mod2.Reader[String] {}

  def builder[M <: Module](m: M): Builder[M] = new Builder[M](m)

  def test =
    val b = builder(mod) // inferred type is Builder[mod.type]
    // b.m.Reader[String] =:= mod.Reader[String]
    b.json[String](stringReader) // ok

    builder(mod).json(stringReader) // no error
    builder(mod).json[String](stringReader) // error: required Nothing

    val b2 = builder(mod2) // inferred type is Builder[Module]
    b2.json[String](stringReader2) // error as expected
    // because we don't know whether b2.m =:= mod2

    builder(mod2).json(stringReader2) // error: required Nothing
    builder(mod2).json[String](stringReader2) // error: required Nothing

    builder[mod.type](mod).json(stringReader) // ok
    builder[mod.type](mod).json[String](stringReader) // ok
    builder[mod2.type](mod2).json(stringReader2) // ok
    builder[mod2.type](mod2).json[String](stringReader2) // ok

[noti0na1]

class Box[T](val i: T):
  val f1: i.type = i
  def f2: i.type = i
  def f3(x: i.type): Unit = ()
  def f4(x: i.type): i.type = i

def box[T](x: T): Box[T] = new Box(x)

def test =
  val a: AnyRef = new AnyRef
  val i: a.type = box(a).i // ok
  val x: a.type = box(a).f1 // ok
  val y: a.type = box(a).f2 // ok
  box(a).f3(a) // error: required Nothing
  val z: a.type = box(a).f4(a) // error: required Nothing

This code shows the behaviour more clear. Let's take f2 and f3 as example: both contain i.type, but i.type in box(a).f2 seems to get correct type from T, but i.type in box(a).f3 gets Nothing.

The type of box(a) is Box[T], where T is type variable bounded by a.type and Any. When we type check the field selection, i.type is dependent on the prefix, but prefix is still not fully instanciated yet, so a Nothing is given to the types at parameter positions during asSeenFrom:

/** Map a `C.this` type to the right prefix. If the prefix is unstable, and
 *  the current variance is <= 0, return a range.
 *  @param  pre     The prefix
 *  @param  cls     The class in which the `C.this` type occurs
 *  @param  thiscls The prefix `C` of the `C.this` type.
 */
def toPrefix(pre: Type, cls: Symbol, thiscls: ClassSymbol): Type = /*>|>*/ trace.conditionally(track, s"toPrefix($pre, $cls, $thiscls)", show = true) /*<|<*/ {
  if ((pre eq NoType) || (pre eq NoPrefix) || (cls is PackageClass))
    tp
  else pre match {
    case pre: SuperType => toPrefix(pre.thistpe, cls, thiscls)
    case _ =>
      if (thiscls.derivesFrom(cls) && pre.baseType(thiscls).exists)
        if (variance <= 0 && !isLegalPrefix(pre))
          approxCount += 1
          range(defn.NothingType, pre)
        else pre
      else if (pre.termSymbol.is(Package) && !thiscls.is(Package))
        toPrefix(pre.select(nme.PACKAGE), cls, thiscls)
      else
        toPrefix(pre.baseType(cls).normalizedPrefix, cls.owner, thiscls)
  }
}

A workaround is passing singleton type a.type to box explicitly, or changing the result type of def box to Box[x.type], so we always get the desired singleton type when typing the selection.

This is a surprising but expected behaviour of type inference and asSeenFrom, so I guess there will be no fix?

Do you agree with this conclusion? @dwijnand @odersky

[odersky]

Yes, I think that's correct. It's because i appears contravariantly, so we approximate by lower bound which is Nothing.

[noti0na1]

I'm not sure if we can give a better result by approximating the lower bound for each part of the prefix type?