Applience LHS only to the last token of RHS

[Alexsey]

I would like to propose a slightly different way of thinking about the F#-style pipeline operator

Its naive interpretation may sound like "take the left side and move it to the right parenthesized". What literally mean

x |> f
 ↳→→→→↴
     f(x)

It's about changing the target of the appliance of LHS from RHS to the last token of RHS. It would allow to solve some problems of current interpretation and make it more ergonomic:

1. x |> await f expression. Because of its ambiguity in the current implementation, it is treated as a Syntax Error. If x would be applied not to await f but only to f there would be no ambiguity and x |> await f may become a valid expression that would mean await f(x)

x |> await f
 ↳→→→→→→→→→→↴
     await f(x)

2. Special case for await - x |> await |> f. Current interpretation treats await in the pipeline as a unary function while in all other places of the language it's a unary operator. Because this use case would be covered with x |> await f the x |> await may become a Syntax Error and await in the pipeline would become a unary operator just like anywhere else
3. The motivation behind parenthesizing of a RHS arrow function. Current motivation is to avoid ambiguity. In new formulation usage without parentheses is not an ambiguity - it's not an invocation any more - it's a function expression

x |> a => b
 ↳→→→→→→→→→↴
     a => b(x)

Definitely, something that is far-far away from what it expects to be. And it will get a real sense only with parentheses

x |> (a => b)
 ↳→→→→→→→→→→→↴
     (a => b)(x)

now it's IIFE! Everyone knows that parentheses are required for IIFE. From some redundancy that was required to escape ambiguity, they become non-questionable part of an actual logic

4. Simple naive formulation would allow to easily explain this feature to new users

It should not conflict with any other part existing proposal

[mAAdhaTTah]

x |> a => b
 ↳→→→→→→→→→↴
     a => b(x)

This is not what's intended by that code. We're attempting to remove the need for paren'd arrow functions here: tc39#104 and I don't think anyone would expect x |> a => b to desugar that way. You're also now moving the value on the LHS into the body of the arrow function on the RHS, which is unprecedented in the language.

You're also still looking at this from the perspective of syntax and not what things are. Pipeline is not series of parentheses transformations, and it doesn't really make sense to explicitly implement it as such.

[mAAdhaTTah]

I'd strongly suggest taking a read through the spec itself to get a sense for how things are defined. I think you'll find it difficult to impossible to actually spec something as a series of parentheses transformations.

[Alexsey]

Sorry for not being explicit enough. I mean that such behavior is the reason why usage of arrow function without parenthesizes should be forbidden. But it's a bad formulation

There is a way to tune the formulation a little bit and this issue would be resolved as well - apply LHS not to the last token of RHS but to the last element of RHS in the same scope. In this case x |> a => b would not become a a => b(x) because b is from other scope

And the question of parenthesizes is getting out of the scope of this discussion

But if the current plans are to remove the need of parenthesizes then this is really become too complex to be