Give The `pipe` Method of `scala.util.ChainingOps` An Operator Representation

Language Design
1

Does anyone think this is a good idea:
Give the pipe method of scala.util.ChainingOps an operator representation.

I’m not sure what operator is the best, but I think |> can be a candidate.

I think an operator representation for the pipe method can make the coding with pipe more natural.

3 Likes
2

pipe is a regular function call which takes a closure, and therefore is highly inefficient for simple things. (The first PR to the Scala library that used it was a refactoring of something simple that unintentionally clobbered performance. The change was caught before going in, IIRC.)

Therefore, its routine use should be discouraged especially in mathematical contexts, so I think the operator version (yes, |> is the usual one for Scala) is a bad idea.

In Scala 3, it’ll be much easier to make it efficient. We should wait until then.

In the meantime, feel free to use it to simplify heavyweight operations or complex logic where the overhead of an extra closure isn’t significant.

Do:

myBigThing.partition(p).pipe{
  case (yesses, nos) => f(nos.tail, yesses)
}

Don’t:

2.7.pipe(cos)
5 Likes
3

Thanks! Your response makes sense for me.

4

|> notation was also choosen by typelevel/mouse

2 Likes
5

the main previous discussion of this was at https://github.com/scala/scala/pull/7326

3 Likes
6

In the linked thread, they especially wanted to line up the operators, which you can do now:

// -Xsource:3
  def f = 42
          |> (_ + 1)
          |> (_.toString)

Perhaps shift-enter in REPL should give you a |> instead of |.

I’m more of a tap man, myself.