Why do we want to have |> but not pipe rather than having |> be the symbolic alias for pipe?

I'm 👍, but I wouldn't be against keeping pipe, especially if that's the requirement for having this.

I suggest marking this (and pipe) as @inline

OCaml

Composition operators

val (|>) : 'a -> ('a -> 'b) -> 'b

Reverse-application operator: x |> f |> g is exactly equivalent to g (f (x)). Left-associative operator at precedence level 4/11.

F#

Function Composition and Pipelining:

Pipelining enables function calls to be chained together as successive operations. Pipelining works as follows:

let result = 100 |> function1 |> function2

Elixir

The pipe operator

iex> total_sum = 1..100_000 |> Enum.map(&(&1 * 3)) |> Enum.filter(odd?) |> Enum.sum
7500000000

The |> symbol used in the snippet above is the pipe operator: it takes the output from the expression on its left side and passes it as the first argument to the function call on its right side. It’s similar to the Unix | operator. Its purpose is to highlight the data being transformed by a series of functions. To see how it can make the code cleaner, have a look at the example above rewritten without using the |> operator:

iex> Enum.sum(Enum.filter(Enum.map(1..100_000, &(&1 * 3)), odd?))
7500000000

ECMAScript proposal

ESNext Proposal: The Pipeline Operator

Swift library

Swift Data Pipelines

R library

R for Data Science: 18 Pipes

The pipe, %>%, comes from the magrittr package by Stefan Milton Bache. Packages in the tidyverse load %>% for you automatically, so you don’t usually load magrittr explicitly.

Here's my original reason for calling it pipe instead of |>: #6767 (comment)

I'm on the fence about this.

The thing is, any one symbolic operator considered in isolation looks appealing. The |> examples look nice, it's no problem... or so it's tempting to think.

But the problem is symbol overload in the language, standard library, and ecosystem as a whole.

I'd be happy for both pipe and |> to exist; even though I can't see myself ever using pipe 😸

I agree that any new operators should be challenged and this is good to see. I really dislike :\ and :/, Those unique or obscure are the sort of operators that should generally be avoided.

However, |> is different to those two as it is common operator for a simple task used by a number of popular languages.

I'll mention ReasonML again, the multi-lining comment in the OP is exactly how I use pipe.

Functions ReasonML

The reverse-application operator (|>)
The operator |> is called reverse-application operator or pipe operator. It lets you chain function calls: x |> f is the same as f(x). That may not look like much, but it is quite useful when combining function calls.

Example: piping ints and strings
Let’s start with a simple example. Given the following two functions.

let times2 = (x: int) => x * 2;
let twice = (s: string) => s ++
If we use them with traditional function calls, we get:

// twice(string_of_int(times2(4)));

• : string = "88"
  First we apply times2 to 4, then string_of_int (a function in the standard library) to the result, etc. The pipe operator lets us write code that is closer to the description that I have just given:

let result = 4 |> times2 |> string_of_int |> twice;

Sometimes symbolic operators like that look nice on paper but quickly fall flat on their face.

Consider a case where we reach a type inference limitation and have to supply the type parameter explicitly:

error |> [Either[String, Int](Left)

yuck

What about formatting a long chain of pipe calls across many lines:

foo
  .|>(bar)
  .|>(baz)
  ...
  .getTheGoodStuff

not cool

What if we want to use case function syntax (and we also have to supply the type parameter and we also want to format):

foo
  .|>[Either[String, Int]] {
    case Bar => Left("error")
    case Baz => Right(42)
  }.|>(...)

This reads like a soup of symbols to me.

foo
  .|>(bar)
  .|>(baz)
  ...
  .getTheGoodStuff

If you want to use dots/braces use pipe (hence it would be nice to offer both). If not use the operator and it looks fine:

foo
  |> bar
  |> baz
  ...
  |> getTheThing

foo
  .|>[Either[String, Int]] {
    case Bar => Left("error")
    case Baz => Right(42)
  }.|>(...)
This reads like a soup of symbols to me.

This would be written as something like:

val either42Function: Foo => [Either[String, Int]] =  {
    case Bar => Left("error")
    case Baz => Right(42)
  }

foo |> either42Function

Btw, whatever the end result, thank you @ScalaWilliam for leading the effort here.

+1 for having |> as an alias to pipe

I think we should keep pipe and add |> as an alias.

+1 for having |> as an alias to pipe

I'll make it an alias.

@japgolly if I use @inline, does it mean I could remove the overhead comment in the scaladoc?
cc @eed3si9n

Applied the change.

@ScalaWilliam I don't think you can remove the Scaladoc comment with just @inline.
My original PR used macro to inline the function call - b7f6955

Right. Thanks for clarifying.

I'm trying these out on a real codebase... and noticed just how similar pipe is to match, except for the case statement.

Yes, hence my comment somewhere or other that we should just allow .match, and for it not to require case, and then we already have pipe built in and it's fast.

@Ichoran that sounds interesting.

For multiline:

I wish we could do this (& imagine the beauty when the pipes are all aligned!):

  1 |> plusOne
    |> plusOne
    |> plusTwo
    |> plusThree

but sadly have to do this instead:

  1 |>
    plusOne |>
    plusOne |>
    plusTwo |>
    plusThree

For single line:

val two1 = one |> plusOne |> plusTwo |> plusThree
val two2 = one.pipe(plusOne).pipe(plusTwo).pipe(plusThree)
val two3 = one pipe plusOne pipe plusTwo pipe plusThree

The first is definitely the most obvious and easiest for scanning, the third is the worst.
The second could also be auto-formatted into a multi-liner:

val two2 = one
  .pipe(plusOne)
  .pipe(plusTwo)
  .pipe(plusThree)

Ref Pre SIP: Demote match keyword to a method.

Another what-if possibility, that might be considered Scala idiomatic is treating Id as datatype like List(...):

val two2 = Id(one)
  .map(plusOne)
  .map(plusTwo)
  .map(plusThree)

@eed3si9n that is very interesting. Pity that I missed all these discussions.

@Ichoran

Yes, hence my comment somewhere or other that we should just allow .match, and for it not to require case, and then we already have pipe built in and it's fast.

Many years ago I proposed that all Functions had isDefinedAt and function literals would automatically have it return true (default method impl) which would make { case _ } a DSL which would generate both the apply and the isDefinedAt, which would mean that Any could have a method named match as in def match[T](f: MyType => T): T.

A consequence of this would be that there'd be no more PartialFunction type, and there would have to be no language support for match. It seemed nice (since any Function/method on the JVM can be partial anyway)

@ScalaWilliam That's a shame about the multiline... but the example shows a solid use case for having pipe alongside |>

I'm trying these out on a real codebase... and noticed just how similar pipe is to match, except for the case statement.

@ScalaWilliam actually you can use pipe, |>, or anything that expects a function, with case statements. For example,

List(Some(1), None) map {
  case Some(_) => true
  case None => false
}

The resulting function will throw a MatchError if a value isn't handled, just like match.

Please see the updated commit. I returned the comment regarding overhead, but put it at the comment of the ChainingOps class.

If I understand correctly, naming it map would allow us to use it in for comprehension. This may not sound like much of a benefit, but allows to skip val which could make a difference for long assignment chains...

Also it promotes the Id monad, which may make more people learn what it is and dive into FP

Seems it's converged now.

If I understand correctly, naming it map would allow us to use it in for comprehension.

True. But it also would mean that any value could be used in a for-comprehension, and that seems undesirable and likely to hide mistakes and typos.

Also it promotes the Id monad...

True, but the "ambient" Id monad (type Id[A] = A) is not a very good representation of the identity monad, largely because it doesn't really exist, so there's no distinguishing Id[List[A]]'s map from List[A]'s map (and in fact, you can't access the former no matter what you want to do. class Id[A](val runId: A) extends AnyVal is a far better identity monad.

@lrytz should these @inline annotations be included? not, right? ("In general, our recommendation is to avoid using these annotations", as your about-to-be-published blog post says)

@japgolly Lukas's blog post explains its recommendations very thoroughly, keep an eye out for it

to summarize the above discussion, to help final review:

• there was discussion of whether we should still keep pipe if we add |>, the consensus was that pipe definitely stays
• there were some tangents about match and map and Id which were interesting, but not ultimately relevant, in the end, afaict, to a thumbs up/down call here

personally, I half want to support this but I'm still wringing my mental hands about "symbol overload in the language, standard library, and ecosystem as a whole", as I said above

I'll try to find out what the rest of the team here at Lightbend thinks

The @inline annotations don't hurt either, and we have many of them already. So I personally don't mind. Maybe one day I'll send a PR that removes them all, last time I checked they had no impact on performance :-)

I don't mind removing them.

• there were some tangents about match and map and Id which were interesting, but not ultimately relevant, in the end, afaict, to a thumbs up/down call here

personally, I half want to support this but I'm still wringing my mental hands about "symbol overload in the language, standard library, and ecosystem as a whole", as I said above

English method name is our default

Ultimately, it comes down to subjective taste of how code written in idiomatic Scala should feel like.

The reason why I am drawing comparison with isometric match and Id#map is because they can act as examples of how Scala code conveying the same meaning feels like.

val something = List("foo")
  .map({ case "foo" => 2; case _ => 3 })
  .map(plusTwo)
  .map(plusThree)

The above hopefully feels idiomatic to many readers, and it does not use symbolic operator to process passed in functions. We say flatMap as opposed to >>=.

when symbolic DSLs are used today

There are certain exceptions to the general English rule, and I can think of the following motivations:

• When the language/library authors want to promote some datatype to give built-in feel.
• When brevity aids readability.

Some examples of the first might be 'foo (Symbol), 1 :: Nil (List), (1, "foo") (tuple), 1 -> "foo" (tuple), "org" %% "name" % "1.0" (ModuleID).

The latter example might be 1.0 + 2.0 (arithmetic operations), 1 + "foo" (any2stringadd), /: (foldLeft).

Note that some of these are actively being deprecated in Scala 2.13. (could someone link to why /: is getting axed?)

what this means for |>?

For the symbolic DSL like |> to be successful, I think it's crucial that it is taught as part of the language early and often, like 1 :: Nil. Otherwise, some of us would use it while the others would be left confused.

To me the benefit of pipe or |> is when you have a big expression in the beginning, and then immediately afterwards you want to pass the result to a function, not the chaining itself.

// using pipe
(Right("foo") match {
  case Right("x") => Some("y")
  ....
  case Right(x)   => None
  case _          => Some("bar")
}) pipe (_.isDefined)

// using |>
(Right("foo") match {
  case Right("x") => Some("y")
  ....
  case Right(x)   => None
  case _          => Some("bar")
}) |> (_.isDefined)

The |> example looks cooler, but doesn't add much in terms of readability.

I'm going to close this, on overall-language-surface-area-especially-when-symbolic grounds, unless someone else from the Scala team speaks up clearly in favor of merging it. going once, going twice, ...

To further explain my 👎: I don't feel that strongly that we need this, but:

• there doesn't seem to be a strong opposition to it (currently 5 👎)
• there seems to be some support for it (currently 25 👍)

So I think on balance it should be merged.

Ideally, we would be able to merge this in some kind of non-committal way, but I don't think we really have one... We're moving away from compiler flags, experimenting in Dotty puts it too far out of reach, having it in an external library also puts it out of reach.

The other options I see are annotating it with @ApiMayChange, like Akka does and would require introducing that annotation, or putting it in some kind of experimental module that ships in the Scala distribution (something like scala-library-experimental).

Or we can just accept this one-liner, and go through the regular deprecation cycle if we change our minds later. 🙂

Proposing @ApiMayChange in #7528, so if that lands we could use it here.

@SethTisue - I'm throwing this one back to you. I don't know how to interpret the discussion, and I object to having pipe at all as something that looks like an alternative to match but in fact is a performance trap for the unwary. So I'm especially not in the frame of mind to decide on pipe alone vs. pipe with |> as an alias.

So sad