JEP 476 analog?

Language Design
9

I note that “optimize away those forwarders ourselves (i.e. the Scala compiler should do it” isn’t an existing feature of export, and would surely break the existing documented semantics? It was proposed, via transparent keyword, by @rssh previously… is that what you are suggesting/implying?

I agree supporting import via export is conceptually plausible. My challenge to anyone who advocates this approach, is to please try, in anger and at scale, using the existing export feature (and just ignore the bytecode bloat for now).

I have tried. I care about import boilerplate, I have a lot and wish I could eliminate it, it bugs me, and Ive tried what’s in Scala 3’s present toolkit to factor it.

As well as the bloat issues I raised here, and the current lack of support for wildcard * exports (also a current dealbreaker), there’s the unpredictable, almost emergent behavior of export itself.

It is far from a well-understood or (yet) widely-used mechanism.

  1. We get a first clue from the official docs: “Export clauses raise questions about the order of elaboration during type checking”.

  2. In this earlier thread about exporting in “overlapping” situations I raised more questions than I got answers. I repeat the appeal I made then: “Particularly, at the appropriate point in the solidification of Scala 3, export’s precise behaviour should be specified so we can confidently predict how it will work in a given situation.”

  3. And in this Scala Users thread on exporting across module boundaries, I raised issues with export semantics that were not documented.

My experience is that export is not yet a well-specified, stable feature that we could confidently layer additional features on top of. As well as the reality that the export of today does something different (ie runtime forwarders) to what’s needed for factoring out of repeated imports.

The import problem is pretty straightforward:

  • A module or an application wants to give a simple alias to a collection of imports spanning multiple packages.
  • Importing the alias imports the underlying collection.
  • Able to share and compose such aliases across libraries/modules, the same way we can share or compose eg def definitions.

I feel dedicated language-level support would turn out to address this problem more simply than trying to re-purpose export.

4 Likes