New syntax for collective extension methods

[odersky]

It's now:

extension listOps on [T](xs: List[T]) with {
  def second = xs.tail.head
  def third: T = xs.tail.tail.head
}

instead of

given listOps: [T](xs: List[T]) extended with {
  ...
}

[odersky]

@bishabosha There's a bunch of semanticdb tests that need to be updated. Can you take care of that? Thanks!

[odersky]

Like its ancestor #7914, this PR changes docs as well as implementation. To avoid confusion, it should be merged just before the next release. so that we can keep the two in sync.

[odersky]

Background and Motivation

Originally, Dotty had only regular extension methods (their syntax just got upgraded in #7914). These extension methods are great since they can be defined everywhere and they can be abstract. That aspect enables in particular the nice expression of infix methods in type classes.

But there was a usability problem: If several concrete extension methods are defined together their type parameters and leading value parameter have to be repeated for each method. The current solution to extension methods with implicit classes does this much better.

Until now we tried several ways to carve out a special case in the syntax for given instances that only define extension methods. But there was always the problem of "false friends": given instances are about types whereas collective extensions describe parameters of extension methods. The two look similar enough to be confusing.

That's why I finally bit the bullet in proposing a completely separate syntax for collective extension methods. It makes things a lot clearer. My previous hesitation to claim extension as a keyword can be worked around by making extension and of soft keywords that are only recognized in tandem.

The extension syntax looks quite similar to what has been added recently to Dart. The main difference is that we still insist on naming the first parameter, whereas Dart repurposes this for referencing this parameter. This choice was made so that normal and collective extension methods follow the same rules.

[He-Pin]

Refs dart-lang/language#41 , it's really glad to see Dotty make this move,Dart do have some fancy stuff

[soronpo]

What happens when you refer to this inside an extension method, both in top-level, and inside a class/object?
Top level:

extension IntOps of (i : Int) with {
  def foo : Int = this.i //Can we refer to `this`?
}

Inside class:

class Foo {
  val i : Int = 0
  extension IntOps of (i : Int) with {
    def foo : Int = this.i //Does `this.i` refer to `Foo.i`, `IntOps.i` or generate an error?
  }
} 

[odersky]

@soronpo It's explained by the expansion: this refers to the extension object itself.

[bishabosha]

looks like one of the tests ran by intent failed in the community build factor10/intent#44

[jdegoes]

I like this. I'd prefer if all the main uses of implicits had totally different syntax:

• type class instances
• extension methods
• automatic conversions
• proofs
• context threading ("reader")

It leads to a different style of learning and teaching.

A developer knows when they need an extension method (more or less). They know when they need a low-friction way to convert between types. They know when they need to prove something to the compiler (e.g. something is a subtype of something else). Etc.

Even though all these things use the same mechanism, they are all different use-cases and most programmers think and learn in a use-case-oriented way.

Indeed, proliferation of use-case specific features is not considered "complexity" by most programmers, even though objectively it inflates the size of the grammar (see C#, Kotlin, etc.).

[dwijnand]

Btw, "extension of" and "extension on" work equally well. But seeing as Dart uses "extension on", copying them keeps future, poly Scala/Dart programmers sane. 😄

[AndreuCodina]

For me, it would be great if the unnnecessary boilerplate is removed because:

• I don't need an explicit reference to the extended type.
• I don't need a name for the extension. You can add it with one keyword or just reference it with some keyword.

The ideal language is easily readable.

Now:

extension on (x: Int)
  def isPositive(): Boolean =
    x > 0

My favourite syntax:

extension Int
  def isPositive(): Boolean =
    this > 0

Important: this is the extended object, and with this you can access to other extended methods too.

My proposal with real code is much less verbose than current implementation.

And personally, I prefer extend because you read it "extend Int" instead of "extension for/on Int".

extend Int
  def isPositive(): Boolean =
    this > 0

[seigert]

I wonder if new syntax will allow for (generalized) type constraints? For example:

extension eitherThrowableOps on [A, E <: Throwable](e: Either[E, A]) {
  def toTry: Try[A] = e.fold(Try.failure, Try.success)
}

or (less preferred)

extension eitherThrowableOps on [A, E](e: Either[E, A])(using ev: E <:< Throwable) {
  def toTry: Try[A] = this.fold(Try.failure, Try.success)
}

Edit: I found in extension methods docs that at least context bounds is allowed for general extension methods, but for collective extensions only example is

extension on [T](xs: List[T])(using Ordering[T]) {
  def largest(n: Int) = xs.sorted.takeRight(n)
}

Is use of context bound is possible there too?