Hacker News Reader

Comment by TehShrike | Hacker News Reader

I was excited for that proposal, but it veered off course some years ago – some TC39 members have stuck to the position that without member property support or async/await support, they will not let the feature move forward.

It seems like most people are just asking for the simple function piping everyone expects from the |> syntax, but that doesn't look likely to happen.

View on HN

I don't actually see why `|> await foo(bar)` wouldn't be acceptable if you must support futures.

I'm not a JS dev so idk what member property support is.

Seems like it'd force the rest of the pipeline to be peppered with `await` which might not be desirable

    "bar"
    |> await getFuture(%);
    |> baz(await %);
    |> bat(await %);

My guess is the TC committee would want this to be more seamless.

This also gets weird because if the `|>` is a special function that sends in a magic `%` parameter, it'd have to be context sensitive to whether or not an `async` thing happens within the bounds. Whether or not it does will determine if the subsequent pipes are dealing with a future of % or just % directly.

It wouldn't though? The first await would... await the value out of the future. You still do the syntactic transformation with the magic parameter. In your example you're awaiting the future returned by getFuture twice and improperly awaiting the output of baz (which isn't async in the example).

In reality it would look like:

    "bar"
    |> await getFuture()
    |> baz()
    |> await bat()

(assuming getFuture and bat are both async). You do need |> to be aware of the case where the await keyword is present, but that's about it. The above would effectively transform to:

    await bat(baz(await getFuture("bar")));

I don't see the problem with this.

Correct me if I'm wrong, but if you use the below syntax

  "bar"
    |> await getFuture()

How would you disambiguate it from your intended meaning and the below:

  "bar"
    |> await getFutureAsyncFactory()

Basically, an async function that returns a function which is intended to be the pipeline processor.

Typically in JS you do this with parens like so:

(await getFutureAsyncFactory())("input")

But the use of parens doesn't transpose to the pipeline setting well IMO

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.

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.

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.

Reply on news.ycombinator.com