aliasing gets less precise type than Scala

[liufengyun]

In Scala, Nil gets the type collection.immutable.Nil.type, but in Dotty it gets scala.collection.immutable.Nil$.

object Test {
  val Nil = scala.collection.immutable.Nil
}

[smarter]

Is this an issue for anything in practice?

[DarkDimius]

In Dotty, scala.collection.immutable.Nil$ will have a self-type collection.immutable.Nil.type. Do you have an example where you'll be able to see a distinction?

[smarter]

There's also a special case in subtyping: #1448, I wasn't sure if that special-casing was the right way to go, so feel free to propose a better solution if this one doesn't work in some cases.

[liufengyun]

The problem I have is the exhaustivity of the following program:

object Test {
  val Nil = scala.Nil
  val X = 5

  def foo1b[T](l: List[T]) = l match {
    case Nil => true
    case x::xs => false
  }
}

The checker will report that Nil is not matched, because:

scala.collection.immutable.Nil.type <:< scala.collection.immutable.Nil$(Test.Nil) = false

The checker can special case, but given that now we also have case val for enum, it would be nice that the checker only rely on the type system.

[smarter]

Ah indeed, that seems like a good reason for changing the inference rule (and reverting #1448).

[liufengyun]

The following code can serve as test case, which is accepted by Scala but rejected by Dotty:

object Test {
  val nil = scala.collection.immutable.Nil
  def f(x: nil.type): Int = 3

  f(scala.collection.immutable.Nil)
}

[smarter]

If you want to try to fix it, it should probably be done in inferredType in Namer: https://github.com/lampepfl/dotty/blob/586113dab51d95f2a606c83b2cd31563ac47a6cf/compiler/src/dotty/tools/dotc/typer/Namer.scala#L971

[liufengyun]

Thanks @smarter for the pointer, I'll play with it .

[liufengyun]

After some thinking, I think this issue might not need to be fixed, as long as:

• we accept the minor discrepancy with Scalac
• we push the responsibility to programmers to explicitly annotate the expected type to avoid widening

With the last assumption, the exhaustivity check works well without problem.

The justification is that code that avoids widening is very rare, maybe 1/10000, it doesn't make sense to make a rarity a rule in the language. In contrast, it justifies for programmers to pay additional efforts for a rare usage, i.e. to annotate the expected type with scala.collection.immutable.Nil.type to avoid widening.

[smarter]

The justification is that code that avoids widening is very rare, maybe 1/10000, it doesn't make sense to make a rarity a rule in the language.

It's not actually that rare, it's a common pattern to alias objects in a different package, e.g. https://github.com/scala/scala/blob/2.12.x/src/library/scala/Predef.scala#L150, https://github.com/lampepfl/dotty/blob/master/compiler/src/dotty/tools/io/package.scala#L16, etc.