Non-definition prefix is in implicit scope, unlike Scala 2

[neko-kai]

Minimized code

trait X {
  trait S
}

class Xa(val internal: X) {
  type S = internal.S
  def s: S = new S{}

  implicit class XS(s: S) {
    def printX: Unit = println(s)
  }
}

object Xa extends Xa(new X{})

object App extends App {
  Xa.s.printX
}

Output

    Xa$$anon$1@55924a6a

The above, unexpectedly, compiles and works with Dotty[1], but not with Scala 2.13[2]

Expectation

It seems like Xa is included in the implicit scope of type Xa.internal.S where Xa is not a direct prefix of S, but is instead only a prefix of its prefix, whereas Scala 2 does not include prefixes of prefixes in implicit scope, but only non-prefix parts of the direct prefix.

[smarter]

Seems like a bug in scalac? The spec says:

The implicit scope of a type T consists of all companion modules of classes that are associated with the implicit parameter's type. Here, we say a class C is associated with a type T if it is a base class of some part of T.

And I don't see any notion of "direct prefix" in the definition of "part" below.

[neko-kai]

@smarter
Yes, the spec does not specify a stop to recursion, but I think the behavior in scalac is deliberate - not limiting the prefix allows completely arbitrary remapping of implicit scopes for any non-top-level identifier purely by re-exporting, I imagine this would hurt the ability to cache implicit scopes because any given implicit scope is determined by the syntactic reference, not by the unique type symbol, if any.

Example: Any type in any object can be attached arbitrary implicits to:

object X {
  final class S
}

object Xa {
  val internal = X
  def s: internal.S = new internal.S

  implicit class XS(s: internal.S) {
    def printX: Unit = println(s)
  }
}

object App extends App {
  val a: Xa.internal.S = new X.S
  a.printX
  
  // same type, aliased differently
  val b: X.S = new X.S
  b.printX // not a member
}

If this is allowed and declared a feature, it would also be inconsistent - re-exporting can remap types in objects, but not types in packages, because you can't assign a package to a val: val internal = java.lang

/cc @SethTisue

[smarter]

not limiting the prefix allows completely arbitrary remapping of implicit scopes for any non-top-level identifier purely by re-exporting

I'm not sure I understand what you mean by "arbitrary remapping", but in your example, withval internal = X, the type of internal is X.type, so when looking up implicits for internal.S we should find all the implicits defined in X too, and when looking up implicits for X.S, if an implicit of type internal.S is in scope, it will be considered applicable.

[neko-kai]

@smarter
I edited the post to show it clearlier - in Dotty currently you can alias the exact same type X.S from multiple prefixes and the implicit scope will be different for differently aliased values, despite the type being exactly the same (but only IFF the prefix of S is an object, not a package):

  // type X.S ascripted as `Xa.internal.S`
  val a: Xa.internal.S = new X.S
  a.printX // has extension method
  
  // exact same type X.S, aliased differently
  val b: X.S = new X.S
  b.printX // not a member

https://scastie.scala-lang.org/C4YZxjeuQpGi4yqKC4nQHg

[smarter]

yeah sure, because the parts of Xa.internal.S include Xa and internal, it can have more stuff in its implicit scope, but I don't see how that's a problem?

[smarter]

Also, scalac doesn't seem to be limited to the direct prefix either, e.g. it compiles the following:

object A {
  implicit val x: A.B.C.S = new A.B.C.S
  object B { object C { class S } }
}
object Test {
  def foo(implicit x: A.B.C.S) = x
  foo
}

[neko-kai]

@smarter
Right. I guess the difference is that scalac does not consider prefixes that aren't prefixes of the symbol at the point of definition. e.g. this doesn't work in scalac, but works in dotty.

object A {
  object B { object C { class S } }
}
object AX {
  final val B = A.B
  implicit val x: AX.B.C.S = new AX.B.C.S
}
object Test {
  def foo(implicit x: AX.B.C.S) = x
  foo
}

Also, note that the spec refers to type projections specifically, not to syntactic paths. If type of B is A.B.type then a projection from it is A.B.type#C.S, not AX.B.type#C.S, unless its type is B.type & A.B.type

[smarter]

And yet the following works with scalac:

object A {
  class B { object C { class S } }
}
object AX {
  object B extends A.B
  implicit val x: AX.B.C.S = new AX.B.C.S
}

object Test {
  def foo(implicit x: AX.B.C.S) = x
  foo
}

To me it just seems like scalac has some weird quirk where it loses some information related to the prefix in some situation, and not like a purposefully made choice.

Also, note that the spec refers to type projections specifically, not to syntactic paths.

I don't follow, we're interested in the parts of AX.B.C.S. That can be written as AX.B.C.type#S and the spec tells us:

if T is a type projection S#U, the parts of S as well as T itself;

So we know that AX.B.C.type is a part of that type, furthermore the spec tells us:

if T is a singleton type p.type, the parts of the type of p;

So AX.B.C is a part of that type too. From that we get all the prefixes of that type.

[neko-kai]

@smarter

object AX { object B extends A.B

This is correct because the prefix of the type AX.B.C.S is now AX.B.C, whereas with a val object AX { val B = A.B it's A.B.C.S

This rule specifically forbids vals from being part of the path, note that it doesn't say "as well as p.type itself".

if T is a singleton type p.type, the parts of the type of p;

Meaning that for object AX { val B: A.B.type = A.B the prefix of AX.B in implicit search is A, not AX.

So we know that AX.B.C.type is a part of that type, furthermore the spec tells us:

AX.B.C can't be part of that type, because the type of AX.B is A.B, the chain of projections is A.type#B.type#C.type#S. I think scalac doesn't do anything quirky here, while you say that any given type has an infinite amount of prefixes with no possible normalized path.

[smarter]

AX.B.C can't be part of that type, because the type of AX.B is A.X

No, the type of AX.B is AX.B.type.

[smarter]

From dotty's point of view, an object just desugars into a val and a class, so there's no reason to treat it differently from any other val.

[neko-kai]

@smarter

No, the type of AX.B is AX.B.type.

What is the relation between AX.B.type and A.B.type that allows this to hold?

object AX {
  val B = A.B
}

val s: AX.B.C.S = new A.B.C.S

How can it simultaneously be exactly the same and have a different path? Scalac allows only one stable path per type, that seems much more reasonable than an infinite amount of paths.

[smarter]

What is the relation between AX.B.type and A.B.type that allows this to hold?

AX.B.type =:= A.B.type, this is true in both scalac and dotty:

object A { object B }
object AX {
  val B = A.B
}
object Test {
  implicitly[A.B.type =:= AX.B.type]

  val a: A.B.type = AX.B
  val b: AX.B.type = A.B
}