Request for comments on exports

Scala Improvement Process
39

@odersky @eyalroth just to confirm, that’s right. I didn’t intend or expect that other overloads of print would call the overridden print, but I can see why my example made it look like that. I guess what you are calling forwarding is what I’m calling delegating. I can switch to using the term ‘forwarding’ from now on to avoid confusion.

The point I was trying to get across was just simply that exports do not handle exporting only one of many overloads, because members are exported by name. And that this results in having to manually forward all other overloads whenever there’s a single overload we don’t want to export.

I appreciate @kai’s counter-proposal, and in my view, getting this proposal to the state of supporting @kai’s solution should be the low bar for approving this SIP within the body of classes/traits/objects. I still think it might result in more confusion than the extends Foo by foo approach though. For instance take this example:

trait A {
  def a1(): Unit
  def a2(): Unit
}

trait B {
  def b1(): Unit
  def b2(): Unit
}

class C {
  def a1(): Unit = ()
}
class D {
  def a2(): Unit = ()
  def b1(): Unit = ()
}
class E {
  def b2(): Unit = ()
}

class Delegator(c: C, d: D, e: E) extends A with B {
  export c._ 
  export d._ 
  export e._
  
  // reader's thought process:
  //
  // wait, how are we implementing A and B? 
  // there's no A or B delegated to, and we aren't
  // implementing them here... hm.... 
  //
  // ..oh uhh ok so some of A is implemented by c, 
  //   some of it is implemented by d. Yet other 
  //   members of d are implementing parts of B, 
  //   and finally e implements the remainder of B.
  //   I think I need to lie down 
}

Also, following the principle of making the “right thing to do” the path of least resistence, I still think that users will tend to omit type ascriptions simply because it’s the path of least resistance. So in practice we’ll get mostly:

export printUnit._

instead of

export (printUnit: Printer)._

If it’s true that the current state of the proposal is really all that is on offer, and we aren’t open to amendments such as either releasing only for packages, or including upcasting and automatic blacklisting to avoid collisions between members, then if it were up to me I would not approve, because of the many issues that together prevent this feature from being used as a codebase grows and introduce accidental coupling.

But now I will try to not take up any more of the oxygen in this thread, and let others speak, since I’ve made many posts now, have a good day :slight_smile: