proposal: Go 2: add elixir-like pipe operator

[BourgeoisBear]

I think Elixir's Pipe Operator would be a slam-dunk for Go.

Without a pipe operator, we write things like this:

s := strings.ReplaceAll(strings.ToLower(strings.TrimSpace(x)), "/old/", "/new")

// or this:

http.HandleFunc("/",
    RequireAuthMiddleware(
        SomeOtherMiddleware(
            LogMiddleware(IndexHandler))))

Two complaints: 1) fussy parenthesis accounting, 2) text reads L-to-R, action happens R-to-L.

With a pipe operator, they could be re-written like this:

s := strings.TrimSpace(x) |> strings.ToLower() |> strings.ReplaceAll("/old/", "/new")

http.HandleFunc("/",
   LogMiddleware(IndexHandler) |> SomeOtherMiddleware() |> RequireAuthMiddleware(),
)

It's a tad longer, but easier to read. The operations have more visual separation, and now both text and action flow left-to-right.

Elixir's pipe operator only passes the first parameter. For Go, it would probably make more sense to pipe as many parameters as the previous call returns.

[bcmills]

This operator is closely related to the function composition operator (∘ in mathematical notation): it has more-or-less the same behavior, but applies the operations in the opposite order (sometimes notated as ⨾). See https://en.wikipedia.org/wiki/Function_composition#Alternative_notations.

It is also closely related to Haskell's monad sequencing operator (>>=), which implies that we should also consider the interaction with error-handling. What should happen if one of the functions returns an error type?

[bcmills]

In a language without partial function application or currying, the major question is: which parameter is elided if the function accepts multiple arguments? You've chosen to implicitly pass the result(s) as the first argument(s), but if adopted I would rather we have some explicit indicator (perhaps _, or the C++-style _1, _2, etc. for multiple arguments):

s := strings.TrimSpace(x) |> strings.ToLower(_) |> strings.ReplaceAll(_, "/old/", "/new")

[BourgeoisBear]

I like the "no magic" aspect of Go, so treat error like any other type. In the few cases where it doesn't flow, we can always go old-school.

I also like your suggestion for an explicit indicator. That is even better!

[ianlancetaylor]

Lots of functions return errors, so I wonder how much real world code could really use this.

[BourgeoisBear]

Here is a library with 1,822 stars just to do this for http middleware. Pipe operator would have the advantage of being compile-time syntactic-sugar rather than runtime.

Also, since we don't have operator overloading, pipe operator could really clean up calculations using alternative number types: bignum, complex, matrix, etc...

That the mathematicians bothered to coin ∘ gives me a little more assurance that there's more to the idea than just western luxury decadence.

[bcmills]

@BourgeoisBear, this may also be an interesting use-case to consider for generics. The ∘ operator in SML and Haskell, for example, is just a function with inline call syntax. In SML, that function has the signature:

val o : ('a->'b) * ('c->'a) -> 'c->'b

That has an interesting (lack of) interaction with the the current Contracts proposal, in that that proposal includes neither infix operators nor variadic contracts.

Even including the Rust-like lightweight function syntax from #21498, I suspect the best you could do is something like:

func Apply(type A, B) (x A, f func(A) B) {
	return f(x)
}

func Seq(type A, B, C)(f func(A) B, g func(B) C) func(A) C {
	return func(x A) C {
		return g(f(x))
	}
}

with a call site like:

s := Apply(strings.TrimSpace(x), Seq(strings.ToLower, |x| { strings.ReplaceAll(x, "/old/", "/new") }))

That's not terrible, but it does lack the syntactic smoothness of your proposal.

[BourgeoisBear]

@ianlancetaylor , @bcmills , if a Go pipe operator has to support error handling, here is my first stab (more thinking-aloud than wish-list here, BTW):

Support optional pipeline-continue parameters (check-expression and fail-result-expression) into each pipe operator--which can reference the "explicit indicators" (as suggested by @bcmills) from the preceding command in the pipeline.

If the check-expression evaluates to true, proceed to next stage in the pipeline. Otherwise, skip remainder of pipeline and treat the corresponding fail-result-expression as the final r-value. All fail-result-expressions must have the same result signature as the last expression in the pipeline.

/*
   |>
      always continues to next stage in the pipeline
   |check-expression; fail-result-expression>
      only proceeds to next stage if check-expression evaluates to true
*/

// convert string to int, double it, convert back to string...
s, err := "1234" |>
          strconv.Atoi(_1) |_2 == nil; "NaN", _2> 
          strconv.Itoa(_1 * 2), nil
// s = "2468", err = nil

s, err := "wxy" |>
          strconv.Atoi(_1) |_2 == nil; "NaN", _2>
          strconv.Itoa(_1 * 2), nil
// s = "NaN", err = 'parsing "wxy": invalid syntax'
// strconv.Itoa() is never called

[deanveloper]

Without a pipe operator, we write things like this: [snip]
Two complaints: 1) fussy parenthesis accounting, 2) text reads L-to-R, action happens R-to-L.

The most common solution is to instead separate the calls into separate lines. As a function gets more complex, it should expand vertically, not horizontally.

Simple rewrites of your examples which fix both of your complaints:

s := strings.ToLower(strings.TrimSpace(x))
s = strings.ReplaceAll(s, "/old/", "/new")

http.HandleFunc("/", func (w http.ResponseWriter, r *http.Request) {
    f := LogMiddleware(IndexHandler)
    f = SomeOtherMiddleware(f)
    RequireAuthMiddleware(f)
})

[BourgeoisBear]

@deanveloper, "it should expand vertically, not horizontally" isn't the win here. Elixir-style pipe operator expands vertically just fine. The win is easier-to-read code and less intermediate variable juggling.

Elixir style:

   put_status(conn, :bad_request)
   |> put_view(ErrorView)
   |> render(:raise, exception: e, trace: __STACKTRACE__)

@deanveloper style:

   t := put_status(conn, bad_request)
   t = put_view(t, ErrorView)
   render(t, "raise", e, STACKTRACE)

The value proposition in Go is actually higher, since variables are typed. What if the type that put_status() returns is not the same as what put_view() returns? More variable juggling:

   t := put_status(conn, bad_request)
   q := put_view(t, ErrorView)
   render(q, "raise", e, STACKTRACE)

And those variables are not free of implications! Do they conflict with or shadow any prior variables? Are they used later in the function? The pipe operator sidesteps these implications, and makes it easier to read and write code in a functional style.

[deanveloper]

Actually, because of semicolon placement rules, it would have to expand like the following:

 put_status(conn, :bad_request) |>
    put_view(ErrorView) |>
    render(:raise, exception: e, trace: __STACKTRACE__)

I'll agree that variable juggling is an issue, but I personally don't think it's one that needs solving. It's a large(ish) language change to fix a very minor issue. If a variable gets redeclared/shadowed, it either will cause a compile error (which is very easy to see) or a go vet warning (my bad, go vet doesn't do this by default). If you don't see it because of go vet, it won't affect outer scope so it may not even cause an issue in the first place. Both method chaining and function-call nesting are anti-patterns in Go and are favorable to saving return values and passing them along, making it so that changes to functions, especially internal ones, are easier to make without needing to restructure all of your code.

For instance, what if you want to change your put_status function to return an error as well as t? Well, now it won't work with the pipe operator anymore, so you have to remove the pipe operator, fix your indentation, declare your variables, add error checking, and pass the variable into put_view. And now you're back to not using the pipe operator.

Not to mention that you would have to do this at every single call-site of put_status.

If you didn't have the pipe operator, the only changes to make is to add , err to your variable declaration, and add a quick error check.

Another case: what if you want to print the result of put_status? You don't have access to the variable, so you either need to navigate to your put_view function and put the fmt.Println in there (which is bad, since it should ideally be at the call-site), or you have to remove the pipe operator, add your variable declaration, fix your indentation, pass your variable to put_view, then put the fmt.Println in.

Without the pipe operator? Just add a new line and put in fmt.Println(t).

Not to mention that Go isn't exactly a fan of using special symbols. There are very few symbols in Go that have special meaning that aren't common, which I have brought up in other proposals before. Here's a quick list of all of the ones in Go that aren't exactly commonplace in my eyes:

• := (although this is debatable since it is both a common pseudocode and mathematics operator)
• <- (the channel read/write operator)