Allow exports in extension clauses

[odersky]

This is part of a long term strategy to deprecate and remove general implicit conversions in Scala.

In the thread https://contributors.scala-lang.org/t/can-we-wean-scala-off-implicit-conversions/4388
we identified two areas where implicit conversions or implicit classes were still essential. One was
adding methods to new types in bulk. This can be achieved by defining an implicit class that inherits
from some other classes that define the methods. Exports in extension clauses provide a similar
functionality without relying on implicit conversions under the covers.

[johnynek]

Is this enough to be able to do C(1) elsewhere? It reads like no to me since only the type is exported. Can we clarify that in the documentation and examples (show if it is allowed or disallowed explicitly)?

[odersky]

One can allocate using type aliases (that's why we can write new StringBuilder for instance, because we have

  type StringBuilder = scala.collection.mutable.StringBuilder

in the Scala package. So that's a general principle, not related to exports.

[bishabosha]

it would be nice if exports of an extension method could unify the parameters, as it stands the extension parameters are appended after, and parameter names are not sanitised:

package app

object StrSyntax {
  extension (s: String) {
    def x2 = s * 2
  }
}

object DeferredSyntax {
  extension (s: String) {
    private def syntax = StrSyntax
    export syntax.x2 //    ==>  extension (s: String) def x2(s: String): String  <--- there are 2 `s` parameters here?
  }
}

@main def Test = {
  locally {
    import DeferredSyntax.*
    val ref: String => String = "Hello, world!".x2 // can we drop the extension parameter list of `x2`?
  }
  locally {
    import StrSyntax.*
    val ref: String = "Hello, world!".x2
  }
}

[bishabosha]

I will request changes due to the issue with hygiene of parameter names

[raquo]

Is it possible to express the StringOps example from this PR's docs in a library written in Scala 2.13 and cross-compiled to Scala 3? I mean, without end users seeing warnings / errors, and without requiring end users to import scala.language.implicitConversions at every use site?

Currently I use Scala 2 implicit conversions to a StringOps value class for that purpose. If the warning is not otherwise avoidable, then maybe the Scala 2 way of doing extension methods could be exempted from the warning for the time being?

[odersky]

@raquo Not sure I understand. If you need to cross-compile, you need to use Scala 2 implicit conversions anyway, and these don't produce a use site warning.

[raquo]

Ah sorry, I must have misunderstood, I thought scala 2 implicit conversions will also throw a warning if cross compiled to Scala 3. All good then!

[bishabosha]

This will need a minor bump as it is a source forward breaking change - I think this could be considered a breaking tasty change (previously it was expected that the prefix should be a stable path) - we should have a forward tasty compatibility test added

[odersky]

This will need a minor bump as it is a source forward breaking change

Yes, agreed.

I think this could be considered a breaking tasty change (previously it was expected that the prefix should be a stable path) - we should have a forward tasty compatibility test added

In fact, the stability requirement is only dropped for paths in extension methods, and exports are expanded out after desugar, so I don't see how this will affect Tasty. I won't have the time to do a forward compatibility test, and believe none is necessary. In any case this should not be a stopper for getting this merged.

[bishabosha]

Another question, should we avoid exporting extension methods (from inside extension block) using the export wildcard - it could be confusing - so best to require explicit export for them

[bishabosha]

exports are expanded out after desugar, so I don't see how this will affect Tasty.

We kept exports in tasty since #10182, they are used by the doctool for example

[bishabosha]

@odersky please may you check the note I added in 77447c8

[odersky]

@bishabosha In fact, it might be better to simply exclude extensions from exports, as you suggested. I see not much use in treating them as normal methods with a new extension slapped on to them. That also opens up the possibility to unify the extension parameters in the future, if we so decide (although I think that future is unlikely since such unification looks like a can of worms).

[bishabosha]

It might be better to simply exclude extensions from exports, as you suggested.

I'll add a commit for this

[odersky]

I am already on it.

[som-snytt]

@adampauls lampepfl/dotty-feature-requests#148 and #9704

[odersky]

No, the spec is not an implementation detail. There is no separate conceptual scope, that's a central point for understanding extension methods. The more we waffle about this, the worse things become.

…

On Mon, Apr 18, 2022 at 10:21 PM som-snytt ***@***.***> wrote: @adampauls <https://github.com/adampauls> lampepfl/dotty-feature-requests#148 <lampepfl/dotty-feature-requests#148> and #9704 <#9704> — Reply to this email directly, view it on GitHub <#14497 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGCKVSNUQOMQQUS46ZS5CDVFW74BANCNFSM5ORUWO6A> . You are receiving this because you were assigned.Message ID: ***@***.***>

-- Martin Odersky Professor, Programming Methods Group (LAMP) Faculty IC, EPFL Station 14, Lausanne, Switzerland

[adampauls]

Well, there is definitely a separate something. Note that this works just fine:

class Outer(x: Int) {self =>
  def show(param1: Int, param2: Int): String = (x + param1 + param2).toString
  class Inner()

  extension (i: Inner)
    private def __this = self
    def show(param1: Int, param2: Int): String = self.show(param1, param2)
    //export __this.show
}

def use: String = {
  val o = new Outer(1)
  val i = new o.Inner()
  i.show(3, 4)
}

I can write show in two different places, but I can't export it from one to the other.

[adampauls]

And I guess to complete the thought, this does not work

class Outer(x: Int) {self =>
  def show(param1: Int, param2: Int): String = (x + param1 + param2).toString
  def show(i: Inner)(param1: Int, param2: Int): String = show(param1, param2)
  class Inner()

  extension (i: Inner)
    private def __this = self
    def show(param1: Int, param2: Int): String = self.show(param1, param2)
    //export __this.show
}

I think this argues for it being okay to simply allow the export and let the erasure check catch any conflicts later, as it already does.

But I now understand that this would at a minimum be a follow-on PR, so I'll stop the chatter here. Thanks for the clarification!

[adampauls]

To complete the thought: you currently can export functions that already have an overload defined in the export scope:

object Other:
  def show(param1: Int): String = "x"

class Outer(x: Int):
  def show(param1: Int, param2: Int): String = (x + param1 + param2).toString
  export Other.show

def use: String = {
  val o = new Outer(1)
  o.show(3)
  o.show(3, 4)
}

And of course if Other.show has the same signature as Outer.show (after erasure), there will be an error. Seems reasonable then to allow exports inside extensions too?

[bishabosha]

@odersky this should be rebased after #14963 to use the correct path type as the prefix for default getters

[som-snytt]

@adampauls That would make an interesting thread on Discussions.

The restriction on eligibility of members for export has to do with the "motivation" in the reference, which is eloquent on composition over inheritance. Arguably, the pattern you advocate risks greater coupling. Also, export allows me to reason about symbols, and not about the erasure of signatures, and also not just about names: for example, beginners ask, If I import X.f and also import Y.f, why isn't f just overloaded? By contrast, exports can introduce an overloaded symbol.

Extension methods are also a tool for managing a name space, i.e., a scope. They introduce methods that are special with respect to applicability: how to invoke them, and the scope that makes them available. At the intersection of these two features, am I aware of f as a special kind of method? It is no longer f from the enclosing class but "reborn"? I am about to wax poetic with the language of Easter. But export is an alias, the way thieves use aliases for scams and deceptions. They are not to be trusted but must be vetted.

I'd be interested in reading Discussions on these topics from people using the features.

[bishabosha]

to check before the release, should this only be under an experimental language feature import? @sjrd @julienrf

[sjrd]

It should ideally be under an experimental import until SIP approval. Until it's officially back on its feet, though, I have bigger fights to fight; I would expect this change to be reasonably uncontroversial. Not that my opinion actually matters ...

[deusaquilus]

I was really, really enthusiastic about this capability but upon further examination it doesn't seem to help me at all 😢.
Here's an overview: https://contributors.scala-lang.org/t/proposed-changes-and-restrictions-for-implicit-conversions/4923/167?u=deusaquilus