Change extension method syntax

[odersky]

It's now

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

given extension (s: String) { ... }

instead of

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

given (s: String) { ... }

I hope that makes it easier to read and to search for.

[sjrd]

Yes!!!

[smarter]

given listOps: extension [T](xs: List[T])

What's the rationale for preferring this over something like:

given extension listOps[T](xs: List[T])

[neko-kai]

What's the rationale for preferring a given prefix at all? If we go for intent over mechanism, then the intent here is to declare extension methods - the fact that an implicit object is involved in this somehow is completely secondary and mechanism-oriented! So, why not:

extension [T](xs: List[T])

[bishabosha]

Well unless you want an import foo.extension then you still need to import the object by name or with import foo.given - so if given is not on the definition its less obvious

[neko-kai]

@bishabosha Why not import individual extension methods by name? IMHO the object is purely a strange implementation detail, why would a top-level extension method not be imported with .given, but a grouped extension method would be? e.g. what's the difference between following two declarations that necessitates the object mechanism to become relevant?

def (i: Int) inc: Int = i + 1

vs.

extension (i: Int) {
  def inc: Int = i + 1
}

[odersky]

What's the rationale for preferring this over something like:

given extension listOps[T](xs: List[T])

Regularity. If a given has a name id, it always looks like id:. This also makes it clearer that the parameters go on the extension methods, not on the wrapper.

[odersky]

@neko-kai It's too late to claim extension as a hard keyword, and it cannot be a soft keyword when used to start a definition -- too much scope for ambiguity.

Besides, these things are givens, they are available in the implicit scope of companion classes and have to be imported as using import given. So it's better to make that clear in the syntax, I believe.

[liufengyun]

The grouped extension method syntax always creates a wrapper object, which is not composable with existing Scala langauge features.

(1) It is impossible to declare a group of abstract extension methods in a trait and later implement them in a class.

(2) It's impossible to bind grouped extension methods to a known object/class/trait

(3) It's impossible to split grouped extension methods to a trait, and mixin the methods in a known class or object.

In contrast, if we allow an object/trait/class may have 0-n extension clauses (each is a grouped extension), we may avoid the problems above.

[odersky]

@liufengyun The object is actually needed for implicit scope semantics. E.g.

class List[+T] with ...

object List with
  given extension [T](xss: List[List[T]]) with
    def flatten: List[T] = ...

To make flatten available without import it has to be put where it is. The other worry about "wrapper-less" grouped extension methods is that it would make all collectively defined extension methods available under their own name in the enclosing scope. I believe it's overall more manageable to default to grouping them with a wrapper that can be imported selectively. But others might prefer the alternative.

[liufengyun]

To abuse the keyword extends to support extension clauses, the code seems can be written as follows:

object List extends [T](xss: List[List[T]]) with
   def flatten: List[T] = ...

The other worry about "wrapper-less" grouped extension methods is that it would make all collectively defined extension methods available under their own name in the enclosing scope. I believe it's overall more manageable to default to grouping them with a wrapper that can be imported selectively.

Depending on whether extends or extension is used (or both), it seems this special case can be subsumed with extension clause:

given extension (x: String) {
   ...
}

given StringOps extends (x: String) {
   ...
}

It's just an anonymous/named given object with 0 templates and 1 extension clause.

[soronpo]

@neko-kai It's too late to claim extension as a hard keyword, and it cannot be a soft keyword when used to start a definition -- too much scope for ambiguity.

I'm sorry, but "too late" in what time-context? FWIW, I proposed using extension back when given was introduced. #7151 (comment)

[odersky]

I'm sorry, but "too late" in what time-context? FWIW, I proposed using extension back when given was introduced. #7151 (comment)

About 10 years too late 😉

[neko-kai]

@odersky

@liufengyun The object is actually needed for implicit scope semantics.

We could make individual extension methods also obey implicit scope. Why not?

The other worry about "wrapper-less" grouped extension methods is that it would make all collectively defined extension methods available under their own name in the enclosing scope. I believe it's overall more manageable to default to grouping them with a wrapper that can be imported selectively. But others might prefer the alternative.

I think that's not a big issue, because due to overloading the names will be available most of the time anyway - it's also extremely intuitive for the user to be able to import methods from a group definition by their name AND easy for the IDE to find these methods and perform auto-import, for an anonymous given extension object how would an IDE even be able to import it selectively, if it's not referable?

[odersky]

We could make individual extension methods also obey implicit scope. Why not?

It would introduce more coupling and make things more complicated. So I am against it in principle, but even more so now where we want to get to feature freeze. There's no time anymore for considering large and sweeping changes.

[nicolasstucki]

Otherwise LGTM