Request for comments on exports

Scala Improvement Process
61

Your original impl field can have type MyImplType, not just the list of traits that are required to be exported (it can be a restriction)
You need to create a duplicated separate field just to export it.
The feature could nicely avoid this.

62

Okay, so this could be useful for import too:

import (impl: MyTrait1).*

But is avoiding a duplicated separate field really worth it?

63

The workaround looks awkward.
You will have strange fields that:

  1. will take space in the source code, distracting from the important code
  2. come up in the completion list
  3. come up in the bytecode.

You will have more than one field in case you need to delegate to several interfaces.

It doesn’t look like the feature requires that much effort, from what I’ve already seen in the Namer.scala.

64

I believe (although could be wrong) the proposed changes in the thread Proposed Changes and Restrictions For Implicit Conversions (2. Bulk Extensions > 2. Allow the qualifier of an export clause to be an expression instead of a stable identifier) would cover your usecase, too.

So something like
export (impl: MyTrait1 & MyTrait2).*

should eventually be possible, as per my understanding and if everything goes right with said proposal.

65

Please take a look at the Transparent term aliases thread, because the same applies to exports.

There are two different uses cases for the export keyword:

  • to define members “from a template” (to copy the declaration and add a forwarding),
  • to automatically import members from another object on a wildcard import.

In the first case, the definition should be opaque, in the second - transparent. However, currently export seems to imply opaque export. Although “forwarding exports” can seemingly also be used as “dual of imports”, this is an implementation detail, not the semantics, which is especially clear in IDEs.

It may be useful to formally distinguish between opaque exports and non-opaque export, in the same way Scala distinguishes between opaque types and non-opaque type aliases. (Another option is to consider transparent exports or inline exports.)

4 Likes