[packetlost]

I don't think |> really can support applying the result of one of its composite applications in general, so it's not ambiguous.

Given this example:

    (await getFutureAsyncFactory("bar"))("input")

the getFutureAsyncFactory function is async, but the function it returns is not (or it may be and we just don't await it). Basically, using |> like you stated above doesn't do what you want. If you wanted the same semantics, you would have to do something like:

    ("bar" |> await getFutureAsyncFactory())("input")

to invoke the returned function.

The whole pipeline takes on the value of the last function specified.

[porridgeraisin]

Ah sorry I didn't explain properly, I meant

  a |> await f()

and

  a |> (await f())

Might be expected to do the same thing.

But the latter is syntactically undistinguishable from

  a |> await returnsF()

What do you think about

  a |> f |> g

Where you don't really call the function with () in the pipeline syntax? I think that would be more natural.

[packetlost]

It's still not ambiguous. Your second example would be a syntax error (probably, if I was designing it at least) because you're missing the invocation parenthesis after the wrapped value:

    a |> (await f())()

which removes any sort of ambiguity. Your first example calls f() with a as its first argument while the second (after my fix) calls and awaits f() and then invokes that result with a as its first argument.

For the last example, it would look like:

    a |> (await f())() | g()

assuming f() is still async and returns a function. g() must be a function, so the parenthesis have to be added.