.|> should have lower precedence than ->

[DhruvaSambrani]

Issue

Doing

data .|> x -> f(x, 2) .|> g

expands to

data .|> x -> (f(x,2) .|> g)

but should expand to

data .|> (x -> f(x,2)) .|> g

Workaround

Add parentheses

[DhruvaSambrani]

Julia 1.5.3 on Windows

[JeffBezanson]

I definitely see the case for this, but this is where precedence starts to get difficult to fit into a total order. For example

x->x => 1

should probably be a function that returns a pair (which it does now). So => is higher than ->. But

1 |> sin => 0

needs to do |> first, since you can't pipe something into a pair. So |> is higher than =>. So |> must be higher than ->.

It's also interesting to note that this might not make a difference. Either way, the result of f(x,2) gets sent to g next. So it might not be urgent to do anything about this. Another possible fix is to add the a |> f(_, 2) |> g notation, which avoids the issue and is nicer anyway. In this context, it's pretty clear that the extent of the closure can just be everything between the pipe operators.

[DhruvaSambrani]

While |> itself doesn't make a difference, .|> does, because the 2 different expansions lead to a broadcast over different things. One would broadcast over the result of the array transformed by f, and the other on each element of the transformed array. I could also just write it without the broadcast, and everything would work, but isn't that the point of the pipe and broadcast? That I can nicely abstract out a sequence of operations on the elements of the iterable?

[DhruvaSambrani]

Also, this could just be me, but I read

1 |> sin => 0

like 1 needs to be piped to sin => 0. Obviously, like you said it doesn't make sense, but that's how I'd read it, and if => had higher precedence |> I wouldn't be surprised. In my head, |> is the last thing that should expand, because like you said, closure should be everything in between pipes

[pranshumalik14]

Yup, I read it the same way as @DhruvaSambrani. Got stuck with the same issue and I think it makes sense for .|> to have lower precedence since it switches the context of what you're broadcasting, and if one needed the behavior as is evident today, then adding parenthesis to signify "inner pipe" in the anonymous function would be logical and make it readable too.

[cmcaine]

I wouldn't know without trying it what 1 |> sin => 0 would do, but it definitely is confusing to me that .|> has higher precedence that ->, this has bit me and others I have worked with several times and makes code with pipes more error prone (because everyone I have worked with has the "wrong" intuition about their precedence).

[pranshumalik14]

I also think that not only .|> but |> should also have lower precedence than -> so that the code follows what the user intuitively wants, which is proper function closure between consecutive pipes unless explicitly told to do otherwise with parentheses. The workaround right now should actually be the ideal way to achieve the code that is parsed right now, i.e. one should write data .|> x -> (f(x,2) .|> g) to actually get what data .|> x -> f(x,2) .|> g does right now, and the same statement (data .|> x -> f(x,2) .|> g) should mean data .|> (x -> f(x,2)) .|> g implicitly. And the same goes for |> with anonymous functions because cases do arise where both |> and .|> are involved (like #38884).

[StefanKarpinski]

I agree that the argument that's the weak point in the case for the current precedence seems to be that 1 |> sin => 0 should parse as (1 |> sin) => 0: yes, you can't pipe something into a pair, but I don't think that's really compelling for making the precedence off |> so high; it seems more like a case for requiring the user to parenthesize the expression as (1 |> sin) => 0 if they want it to work. That said, I'm not sure that we can change the precedence of |> in a 1.x release without potentially breaking too much code.

[pranshumalik14]

Right, that's understandable, and though it is a breaking change I doubt people would have used x .|> y -> f(y) |> g to purposely mean x .|> y -> (f(y) |> g). If not now, maybe consider it for 2.x? Because there are a more cases where people have had trouble with this "hideous" parsing, for example: https://discourse.julialang.org/t/help-understanding-broadcasted-pipe-operator/30591.

[jonniedie]

A similar observation from another user:

https://discourse.julialang.org/t/pipe-operator-quiz-can-you-guess-the-result/46054