import shadows enclosing packaging

[som-snytt]

Compiler version

Scala compiler version 3.0.0-M3 -- Copyright 2002-2020, LAMP/EPFL

Minimized code

// test.scala
package p {
  class C
}

package q {
  package p {
    class K {
      import _root_.p
      def f() = new p.C
    }
  }
}

Output

Hey, it compiles!

Expectation

An import cannot shadow an enclosing definition.

s/package p/object p results in expected ambiguous reference.

Arguably a package is not a definition, the symbol is introduced by a packaging.

Here, q.p is made available via packagings in the current compilation unit; for definitions, that binding is higher precedence than an import.

Possibly, this behavior is expected or understood, and the spec should say explicitly that bindings of names of packagings are always of least precedence.

[odersky]

The behavior is as expected. Package definitions are not definitions.

I think we will need a separate repo for spec bugs and suggestions

[som-snytt]

This ticket duplicates #9889 which has a slightly more compelling test case, where multiple package util compete.

The ergonomics is to avoid ambiguity with enclosing packages:

package mutable {
  import collection.mutable
  def f() = mutable.ListBuffer.empty[Int]   // obviously OK?
}

That example was obviously OK to me until a second ago, when I felt déjà vu. When bugs in imports were fixed on Scala 2, some code with illegible expectations broke. Like the old joke about variance, "Add import util._ until it compiles."

(Edit: the clarifying comment with a similar example was added to the Scala 2 spec several years ago. Unfortunately, the note includes the misnomer, "package definition", instead of "packaging".)

This ticket and the linked ticket can be closed or moved to spec-land or the RAQ for rarely asked questions.

[som-snytt]

Closing in favor of an explanatory FAQ or RAQ about what is a packaging?