Request for comments on exports

Scala Improvement Process
5

Let me address two very good questions:

Feature interactions

Possible feature interactions should be minimal since exports are completely resolved by Namer. The “export” construct does not even exist as a typed tree. Exports are entered into the symbol table as a set of forwarders. Afterwards, it is no longer relevant that these forwarders came from exports. There’s one (tiny) exception: export forwarders of givens are never cached in a separate variable, since we know that the original given was already cached if necessary. That’s the only case whether something after Namer makes a distinction whether something is an export or not.

but I’d also expect a restriction on a wildcard selecting ineligible members(?)

No, a wildcard will simply export all eligible members.

My remark applied to something else. It is best shown in the following example:

object A {
  def f: String = ""
}
trait B {
  def f: String = "abc"
}
object C extends B {
  export A._   // error: export forwarder for `f` cannot override `f` in `B`
}
object D extends B {
  object b extends B
  export b._    // OK, but nothing is exported
}
object D2 extends B {
  object b extends B
  export b.f    // error: `f` is not eligible
}

Here, the wildcard import in C will create a forwarder for f, since f is eligible by the rules. But that forwarder will then lead to an error. On the other hand, the wildcard import in D will not create a forwarder since the f in b is not eligible because the same f is already defined in a supertrait of D. If we mention f by name as in the export in D2, we get the other error: namely that we are trying to export something that is not eligible.

4 Likes