Proposal to add Extension Methods to the language

Scala Improvement Process
31

I think this is a great approach to extension methods, and it would ultimately simplify Scala.

There would be 2 ways to do it.

More focused one (only for case where the first parameter block has one member):

case class A(...)
def f(a: A)(b: B, c: C): D = ...
a.f(b, c) // de-sugars to f(a)(b, c)

Broader one:

case class A(...)
def f(a: A, b: B, c: C): D = ...
a.f(b, c) // de-sugars to f(a, b, c)

Currently there is a tension between function application and method selection and call. This would basically make the distinction almost meaningless.

Also, currently function application is not very practical (annoying, actually) in contrast to method selection and call, because it requires nesting parentheses:

f(g(h(x))) // nested parentheses, so ugly and annoying to write

is not as elegant as

x.h.g.f

There is this problem of applying function to an argument, but without any “nesting” in the syntax, like ( and ).
Other languages deal with this in their own way.

F# (and many others) has |> operator

x |> h |> g |> f

Haskell has $

f . g . h $ x
-- or
f $ g $ h $ x

There is a language called Koka which does something like was proposed above

a.f(b, c) ~~> f(a, b, c)

I see 2 benefits in adopting this extension methods approach:

  1. simplifying syntax (the necessity of nesting () is a wart IMHO)
  2. decrease the difference between thinking of and using functions vs methods

If Scala adopted this, it would even more unify functions and methods, which would be a solution true to Scala’s mission to marry functional and object-oriented programming.

3 Likes