Pipe-forward operator |>

Looks like you are talking about Functor (see e.g. Haskell).

A functor is defined upon it’s context and leaves it context intact. E.g. a map function on a List class results in a List with transformed values, the context List remains the same. This is “just” applying a function.

Back to the topic, I think adding new operators to the Kotlin should be done rarely. If you do fancy all kinds of operators there are already plenty of languages that fill that spot, with Scala being the obvious one. I agree with sodiaan that, when familiar with pipe-forward operators, this example is very readable. But omitting parameters can be considered as unreadable too.

I find the following almost just as easy to read (and write) without the need for any special language constructs.

val v = validate(request) 
val p = persist(v) 
val n = notify(p) 
return getResponse(n);
1 Like

Exactly! And in a former problem:

request |> validate() |> persist() |> notify() |> getResponse();

We actually have such a context but hidden, it is something like IO monad.

But of course I do not agitate to introduce monads into Kotlin, but just want to emphasize that the problem bay be generalized in some way to make |> or other like that more general mechanism in Kotlin,

What kind of complexity it adds to language?

Here is the gist with some not very nice implementation of pipe forward operator(unary plus in a gist), it is steel required to have some aid from Kotlin lang designers to make it elegant in usage.

In short, we need an operator ‘|>’ which actually converts a:

(T) -> T1


<T>.() -> T1

and have a nice syntax support for usage in a Kotlin lang because it is not very nice to see it as:


I am trying to say, what if to make it possible for any function be used as an extension function? That is if we have:

fun func1(a1 : T1, a2 : T2, ..., a_n:Tn) : Tz

then it would be also seen as:

fun T1.func1(a2 : T2, ..., a_n:Tn) : Tz

In such a case it would be even possible:

. validate(someArg1) 
. persist(someArg2, someArg3) 
. notify() 
. getResponse();

Every feature adds complexity. It’s just another construct we need to learn, be able to read and write and of course a compiler needs to compile.


I like the idea of having the ability to call any function like an extension. There are plenty of Java libraries with classes containing static utility methods which may be called like this.

In Kotlin, this is usually achieved by declaring extension functions and using library combinators such as let, apply, and run.

.let { validate(it) }
.let { persist(it) }
.let { notify(it) }
.let { getResponse(it) }

Still, there is a difference between functions with receivers and functions without receivers, and it can get quite messy:

.run { validate() }
.apply { persist(this) }
.let { notify(it) }
.run { getResponse() }

(in fact, I hit that issue in F# code multiple times: F# |> works with free functions, but not object methods).

So, yes, some sort of “unified function call” operator might me helpful.


I suggest to use the unicode sign “phone” (since phones are used to call) for it: ✆ or :phone:



In addition to @vjache’s comment it would be great to have some option to import function as an extension. I had this idea for a long time. As soon as I read the reference I constantly feel a lack of such functionality. Unfortunately I’m not a Kotlin user, just a fellow traveler. As for me let constructs are not elegant in such cases.

But of course there are some issues to be discussed about like:

  • allowing not only the first argument to be treated as receiver;
  • selective import of overloaded functions;
  • import with wildcard;
  • etc.

Maybe I’m wrong, but you can do that by creating a little (inline) non-member helper function that makes the right calls. Some of the issues with imports (where it is limited) could be handled the same way.

1 Like

If we do ANYTHING along these lines, I recommend going vjache’s route, especially since plain functions and extension methods are both just implemented as static methods in Java. In reality, the only difference between a function call and a method call is how you pass in the primary parameter.

Now, personally, I don’t think this needs to be implemented in any way at all. If we really need to string along some function calls, we can make our own versions as extension methods and chain dot operators. We certainly don’t need a pipe operator.

1 Like

Why is it so complex to parse the first parameter as this-instance?
Isn’t this what Java internally actually does, passing this as first parameter and accessing it via byte-code instruction aload_0?

1 Like

This would be a backwards incompatible change, because it would create overload resolution conflicts or change the way overloads are resolved in cases when you have a method and an extension function with signatures differring by one parameter in Kotlin 1.0 code.


I know, but with your solution one should maintain a zoo of extension functions from project to project for different set of libraries. With appropriate import option it should became less messy.

After fiddling with the problem, I finally wrote those:

fun add(x: Int): Int = x + 1
fun mul(x: Int): Int = x * 12

class Pipe<out A>(val v: A) {
    inline infix fun <B> andThen(function: (A) -> B) = Pipe(function(v))

infix fun <T, R> T.into(other: (T) -> R) = Pipe(other(this))

fun main(args: Array<String>) {
    5 into ::add andThen ::mul andThen ::println

I think it works quite great without adding anything to Kotlin itslef

You do not need the Pipe class for that. You do always create an object for each result, but why?

infix fun <T, R> T.into(func: (T) -> R) = func(this)

should be sufficient. It looks like that:

fun main(args: Array<String>) {
     args[0].toDouble() into ::sqrt into Double::inc into ::println

I think, that would make the operator pretty much useless, because it is just one line of code enabling the rail (or pipe or whatever).

It can be done in many ways, below code worked very well with me:

package hello

fun main(args: Array<String>) {
    var a = 3
    val b: Int = 6

    println("Hello World! doubling, then tripling the sume of $a and $b is " +
                    next ::dbl
                    next ::trpl

    println("Hello World! doubling, then tripling the sume of $a and $b is " +
                    .let (::dbl)
                    .let (::trpl)
    println("Hello World! doubling, then tripling the sume of $a and $b is " +
                    .run (::dbl)
                    .run (::trpl)

    println("Hello World! doubling, then tripling the sume of $a and $b is " +
                    into (::dbl)
                    into (::trpl)

fun sumx (x: Int, y: Int) : Int = x + y
fun dbl (x: Int): Int = x * 2
fun trpl (x: Int): Int = x * 3

infix fun <T, R> T.next(map : (T) -> R) : R = map(this)
infix fun <T, R> T.into(func: (T) -> R) = func(this)

The output is same in all cases, as:

Hello World! doubling, then tripling the sume of 3 and 6 is 54
Hello World! doubling, then tripling the sume of 3 and 6 is 54
Hello World! doubling, then tripling the sume of 3 and 6 is 54
Hello World! doubling, then tripling the sume of 3 and 6 is 54

FWIW, a pipe-forward operator would be very much welcome, and it seems within the idiom of the language.

For example, the coroutine documentation makes references to pipelines – it would be useful to be able to pipe coroutines together
|> coroutine1
|> coroutine2
|> coroutine3